DEV Community

Vigilmon
Vigilmon

Posted on

How to Monitor Your Ruby on Rails App with Uptime Checks and Sidekiq Heartbeats (free)

#rails #ruby #devops #monitoring

How to Monitor Your Ruby on Rails App with Uptime Checks and Sidekiq Heartbeats (free)

Your Rails app just went down at 3 AM and you found out when a customer emailed you the next morning. Sound familiar?

Most Rails tutorials cover deployment — but almost none cover what to do after you deploy. By the end of this article you'll have HTTP uptime monitoring, Sidekiq heartbeat checks, Slack alerts, and a public status page — all in under 30 minutes, free.

The two failure modes Rails developers miss

Rails production failures cluster into two patterns that are easy to detect but go unnoticed without the right tooling:

Endpoint outages — your /api/health or root URL starts returning 500s or timing out. Users see a broken page, but you don't know until they complain (or worse, they don't complain and just leave).

Silent background job failures — your Sidekiq jobs stop running. The database stops being updated, emails stop going out, Stripe webhooks stop being processed. No exception is raised. Nothing shows up in your logs. You just quietly stop getting results until something downstream explodes.

Both are fixable with a few lines of code and a free monitoring account.

Step 1: Add a health check endpoint

Add the health_check gem to your Gemfile:

# Gemfile
gem 'health_check'
Enter fullscreen mode Exit fullscreen mode

Run:

bundle install
Enter fullscreen mode Exit fullscreen mode

Mount the engine in your routes:

# config/routes.rb
Rails.application.routes.draw do
  mount HealthCheck::Engine, at: '/health'
  # ... your other routes
end
Enter fullscreen mode Exit fullscreen mode

Configure what to check:

# config/initializers/health_check.rb
HealthCheck.setup do |config|
  config.standard_checks = ['database', 'cache', 'migrations']
  config.full_checks = ['database', 'cache', 'migrations', 'email']
end
Enter fullscreen mode Exit fullscreen mode

Now GET /health returns healthy with a 200 when everything is fine and a 500 with details when something is wrong. This single endpoint gives you immediate visibility into your database connection, cache, and migration state.

You can test it locally:

curl http://localhost:3000/health
# healthy
Enter fullscreen mode Exit fullscreen mode

Step 2: Set up HTTP uptime monitoring

With your health endpoint live, point Vigilmon at it:

  1. Sign up for a free account at vigilmon.online
  2. Click New Monitor → HTTP
  3. Enter https://yourdomain.com/health
  4. Set check interval to 5 minutes (free tier)
  5. Save

Vigilmon will now ping your endpoint every 5 minutes from multiple locations. If it goes down, you get alerted before your users notice.

You can also monitor your critical API routes directly:

  • https://yourdomain.com/api/v1/ping — confirms the API layer is responding
  • https://yourdomain.com/ — confirms the frontend is serving

Step 3: Heartbeat monitoring for Sidekiq jobs

HTTP monitoring catches server outages. But what about Sidekiq workers that stop running silently?

The heartbeat pattern: your job pings a URL at the end of every successful run. If Vigilmon stops receiving that ping within the expected interval, it knows the job has stopped or failed.

Here's a Sidekiq worker with a heartbeat ping:

# app/workers/daily_report_worker.rb
class DailyReportWorker
  include Sidekiq::Worker

  sidekiq_options queue: :default, retry: 3

  def perform
    # Your actual job logic
    generate_daily_report

    # Ping the heartbeat URL on success
    heartbeat_url = ENV['DAILY_REPORT_HEARTBEAT_URL']
    if heartbeat_url.present?
      Net::HTTP.get(URI(heartbeat_url))
    end
  rescue => e
    # Don't ping on failure — the absence of a ping IS the alert
    Rails.logger.error("DailyReportWorker failed: #{e.message}")
    raise
  end

  private

  def generate_daily_report
    # your logic here
  end
end
Enter fullscreen mode Exit fullscreen mode

For jobs that run on a schedule (via sidekiq-cron or whenever), set the heartbeat URL in your environment:

# .env or your deployment environment
DAILY_REPORT_HEARTBEAT_URL=https://vigilmon.online/heartbeats/your-unique-token
Enter fullscreen mode Exit fullscreen mode

In Vigilmon, create a Heartbeat Monitor:

  1. Click New Monitor → Heartbeat
  2. Set the expected interval (e.g. every 24 hours)
  3. Copy the unique ping URL
  4. Paste it into your environment as DAILY_REPORT_HEARTBEAT_URL

Now if your worker fails midway, raises an unhandled exception, or simply stops being enqueued — Vigilmon will alert you within one missed interval.

Works with Sidekiq cron schedules

If you're using sidekiq-cron:

# config/schedule.yml
daily_report:
  cron: "0 9 * * *"
  class: "DailyReportWorker"
  queue: default
Enter fullscreen mode Exit fullscreen mode

The heartbeat approach monitors the actual execution, not just whether the job was enqueued. A cron schedule that runs but immediately errors will still miss its ping, triggering an alert.

Step 4: Webhook alerts to Slack or email

Configure alert delivery in Vigilmon:

For Slack:

  1. Create an incoming webhook in your Slack workspace
  2. In Vigilmon, go to Notifications → New Channel → Slack
  3. Paste your webhook URL
  4. Enable it on each monitor you want it to cover

For email:

  1. In Vigilmon, go to Notifications → New Channel → Email
  2. Enter the address (or distribution list)
  3. Enable it on your monitors

You'll get alerts like:

🔴 DOWN: yourdomain.com/health
Status: 500 Internal Server Error
From: US-East, EU-West
Started: 3 minutes ago
Enter fullscreen mode Exit fullscreen mode

And recovery notifications:

✅ RECOVERED: yourdomain.com/health is back UP
Downtime: 11 minutes
Enter fullscreen mode Exit fullscreen mode

For the heartbeat monitor:

🔴 MISSED: DailyReportWorker heartbeat
Expected every: 24 hours
Last ping: 26 hours ago
Enter fullscreen mode Exit fullscreen mode

Step 5: Public status page

A public status page lets your users self-serve the "is it just me?" question. It also builds trust — transparency during incidents keeps customers from churning.

In Vigilmon:

  1. Go to Status Pages → New Status Page
  2. Name it (e.g. "Acme Status")
  3. Select the monitors to display
  4. Save and copy the public URL

You can link to it from your site footer, your README, or your error pages. During an incident, users who hit the status page know the team is aware — they don't need to open a support ticket.

What you've built

What How
HTTP uptime monitoring health_check gem + Vigilmon HTTP monitor
Database / cache health health_check standard checks
Sidekiq job monitoring Heartbeat ping at end of each worker
Instant alerts Slack or email webhook notifications
Public status page Vigilmon status page

The full setup costs $0 on Vigilmon's free tier and takes less time than tracking down a silent failure that's been running for two days.

Next steps

  • Add a heartbeat for each critical Sidekiq worker, not just the daily ones — treat them like uptime monitors
  • Monitor response time trends: a gradual slowdown before a crash is often detectable hours in advance
  • Add lograge for structured Rails logs that pair well with monitoring dashboards

Get started free at vigilmon.online.

Top comments (0)