How to Monitor Ruby on Rails Applications for Uptime

Ruby on Rails powers a surprising number of production web applications — from early-stage startups to large-scale platforms like GitHub, Shopify, and Basecamp. Rails applications have a distinct architecture that requires a tailored approach to uptime monitoring.

This guide covers practical Rails application monitoring — health endpoints, background job monitoring, database checks, and alert configuration.

Rails Application Components to Monitor

A production Rails deployment typically includes:

• Puma or Unicorn web server — handles incoming HTTP requests
• Rails application — the application code
• PostgreSQL or MySQL — primary database
• Redis — caching, session storage, Action Cable, Sidekiq queue backend
• Sidekiq — background job processing
• Active Job scheduler — periodic task execution

Each component can fail independently. A Sidekiq process dying won't prevent your web app from responding, but emails stop sending and background processing halts.

Step 1: Add a Health Check Endpoint

Add a dedicated health endpoint that verifies your application stack:

Using the healthcheck gem

# Gemfile
gem 'health_check'

# config/routes.rb
health_check_routes

Or add a minimal custom controller:

# app/controllers/health_controller.rb
class HealthController < ApplicationController
  skip_before_action :authenticate_user!, raise: false

  def show
    ActiveRecord::Base.connection.execute("SELECT 1")
    render json: { status: 'ok' }
  rescue => e
    render json: { status: 'error', message: e.message }, status: 503
  end
end

# config/routes.rb
get '/health', to: 'health#show'

This checks database connectivity and returns 503 on failure. Point your uptime monitor at /health.

Step 2: External HTTP Uptime Monitoring

With your health endpoint in place, configure an external monitor:

• URL: https://yourdomain.com/health
• Method: GET
• Expected status: 200
• Content check: "status":"ok"
• Interval: 1 minute for production

External monitoring from Domain Monitor confirms your app is reachable from the public internet — it catches networking failures, server crashes, and SSL issues that internal checks might miss.

Step 3: Monitor Sidekiq with Heartbeats

Sidekiq is one of the most common failure points in Rails applications. Workers can die due to memory limits, signal handling issues, or deployment problems — and unlike web requests, failed jobs don't immediately manifest as user-visible errors.

Add a periodic heartbeat job to your Sidekiq configuration:

# app/workers/health_ping_worker.rb
class HealthPingWorker
  include Sidekiq::Worker

  def perform
    require 'net/http'
    Net::HTTP.get(URI.parse(ENV['HEARTBEAT_URL']))
  end
end

# config/schedule.yml (with sidekiq-cron)
health_ping:
  cron: "*/5 * * * *"
  class: HealthPingWorker

If Sidekiq stops processing jobs, the heartbeat stops arriving, and you receive an alert. See heartbeat monitoring for full details.

Step 4: Monitor Action Cable and WebSockets

If your Rails app uses Action Cable for real-time features, consider monitoring your cable endpoint separately. A basic HTTP check on the cable mount point confirms the WebSocket upgrade path is available.

Step 5: Database and Redis Health

Your health endpoint should check both database and Redis connectivity:

def show
  checks = {}

  # Database check
  ActiveRecord::Base.connection.execute("SELECT 1")
  checks[:database] = 'ok'
rescue ActiveRecord::ConnectionNotEstablished => e
  checks[:database] = 'error'
  return render json: { status: 'error', checks: checks }, status: 503
end

begin
  # Redis check
  Redis.current.ping
  checks[:redis] = 'ok'
rescue Redis::CannotConnectError => e
  checks[:redis] = 'error'
  return render json: { status: 'degraded', checks: checks }, status: 503
end

render json: { status: 'ok', checks: checks }

This gives your monitoring tool clear signal: the app is up, the database is up, Redis is up.

Monitoring Heroku Rails Deployments

Rails applications on Heroku have some unique monitoring considerations:

• Dynos restart — Heroku restarts dynos daily; monitor for extended unavailability during restarts
• Boot time — Rails apps on Heroku can take 30-60 seconds to boot after a dyno restart; your monitor should not alert on the first 1-2 failures after a deploy
• Heroku scheduler — if you use Heroku Scheduler for cron tasks, add heartbeat monitoring to those tasks

For Heroku deployments, see also how to monitor Heroku applications.

SSL and Domain Monitoring

Don't forget SSL certificate monitoring and domain expiry monitoring — these are independent of your Rails stack but can take your app offline just as effectively as an application crash.

Alert Configuration

Configure alerts via email, SMS, and Slack. For Rails applications, Slack is particularly useful — a #rails-monitoring channel means your engineering team sees alerts immediately during business hours.

A Complete Rails Monitoring Checklist

• /health endpoint checking database + Redis connectivity
• HTTP uptime monitor on health endpoint (1 min interval)
• HTTP uptime monitor on primary application route
• Sidekiq heartbeat monitoring
• SSL certificate monitoring
• Domain expiry monitoring
• Multi-location checks enabled
• Alerts configured: email + SMS + Slack
• Maintenance windows for deployments

Monitor your Ruby on Rails application at Domain Monitor.

Related Articles

• "How to Monitor Django Applications for Uptime and Performance"
• "How to Monitor Heroku Applications for Uptime and Reliability"
• "How to Monitor Laravel Applications for Uptime and Health"