Sidekiq monitoring
The Sidekiq Web UI shows queues, retries and dead jobs while you look at it; to be told when Sidekiq stops processing, run a canary job every 5 seconds that pings a Logdash push monitor.
Sidekiq rarely crashes loudly. Redis fills up, a deploy leaves the process quiet, a long job holds every thread, or the cron poller stops enqueuing. The Web UI shows each of these if you open it. Nothing tells you to open it.
Keep the Web UI for what it is good at. Mount Sidekiq::Web and you get busy threads, queue sizes and latency, retries, dead jobs and memory per process, and Sidekiq 7 added a Metrics tab with execution time per job class. Use it for the questions you ask while looking. The canary is for the one you need answered while asleep.
So watch the outcome instead of the parts: a tiny job that sidekiq-cron enqueues every 5 seconds and that pings Logdash when a thread runs it. Redis, the poller and at least one free thread all have to work for the ping to arrive.
Sidekiq cron monitoring: the canary job
require "net/http"
class LogdashHeartbeatJob
include Sidekiq::Job
sidekiq_options retry: false # a late ping is worthless
PING_URL = URI("https://api.logdash.io/ping/68b4c1f0e3a2d5c7b9f01234")
def perform
Net::HTTP.post(PING_URL, "")
end
end
# config/initializers/sidekiq.rb
Sidekiq::Cron.configure do |config|
config.cron_poll_interval = 2 # default 30 is slower than the window
endlogdash_heartbeat:
cron: "*/5 * * * * *" # six fields: every 5 seconds
class: "LogdashHeartbeatJob"Both settings matter. sidekiq-cron accepts a sixth field for seconds, and it only checks for due jobs every 30 seconds by default, with Sidekiq's random jitter on top. Logdash wants a ping inside every 15-second window, so the poller has to run far more often than that.
Sidekiq scheduler monitoring
On the sidekiq-scheduler gem the job class is the same and the schedule is every: "5s". Sidekiq Enterprise periodic jobs run at most once a minute, too slow for the window, so use either gem for the canary even on Enterprise.
What a missed window means
Push monitors are a Pro feature. On Pro, Logdash looks for a ping every 15 seconds and marks the monitor down on the first window without one, with no grace setting. That makes the canary a backlog alarm too: if every thread is busy for 15 seconds, you hear about it. If your jobs are long by design, give the canary a Sidekiq 7 capsule: its own queue with one dedicated thread, so busy workers cannot starve it. Nightly jobs need a different check, since they cannot ping every 15 seconds: set a Redis key with a 26-hour expiry when the job finishes and point an HTTP monitor at a route that returns 503 once it is gone.
- Create a push monitor Add a service on Pro, set the monitor to push and copy the id from the ping URL into PING_URL.
- Deploy and watch it turn up Restart Sidekiq so it loads config/schedule.yml. The job shows on the Cron tab if you mounted sidekiq/cron/web, and the monitor goes up on the next check.
- Stop Sidekiq Connect a Telegram channel, then stop the process. Within 30 seconds a Telegram alert says the monitor is down, and another arrives when Sidekiq comes back.
Logdash vs Cronitor for Sidekiq
| Feature | Logdash | Cronitor |
|---|---|---|
| Coverage | One canary for the whole process | Server middleware reports every job class |
| Schedule sync | None, the canary has a fixed cadence | Syncs sidekiq-scheduler and Enterprise periodic jobs |
| Time to alert when Sidekiq stops | 15 to 30 seconds | When the next scheduled job is late |
| Logs from the Rails app | Ruby SDK into the same service | Job events, not application logs |
| Free plan | Push monitors start at Pro, $15 a month | 5 monitors |
When Cronitor is the better pick
- You want every job class watched for failures and run time, not one canary.
- Your scheduled jobs run hourly or nightly and you want schedule-aware late alerts without writing a route per job.
- You want email or Slack alerts. Logdash sends Telegram and webhooks only.
- You run Sidekiq Enterprise and want periodic job schedules synced to monitors in one command.