---
title: "Sidekiq monitoring with a canary job | Logdash"
description: "A sidekiq-cron canary every 5 seconds, a push monitor that alerts on the first 15-second gap, and when Cronitor is the better pick."
url: https://logdash.io/cron-monitoring/sidekiq
---

# 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

 app/jobs/logdash\_heartbeat\_job.rb 

```ruby
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
end
```

 config/schedule.yml 

```yaml
logdash_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.

1. **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.
2. **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.
3. **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.

### What should Sidekiq monitoring cover? 

Three things: is anything being processed, are retries and dead jobs piling up, and did the scheduled jobs run. The Web UI answers the second when you look. The canary answers the first without you looking.

### Does Sidekiq have a health check? 

Open-source Sidekiq has no HTTP health endpoint; its wiki suggests a file-based Kubernetes readiness probe. Sidekiq Enterprise 7.1.2 added config.health\_check on a private port, and the sidekiq\_alive gem adds one by having a job refresh a Redis key. None of them pages you on their own.

### Does Sidekiq cron monitoring see each cron job? 

Not with the canary. It proves the poller enqueues and a thread runs jobs. To watch a specific nightly job, use the Redis key plus HTTP monitor pattern, or Cronitor.

### Does Sidekiq scheduler monitoring work the same way? 

Yes. With sidekiq-scheduler, schedule the same job class with every: "5s" and skip the sidekiq-cron poll interval setting.

## Keep reading

[All cron monitoring guides](https://logdash.io/cron-monitoring): One guide per scheduler, each with the code that proves a job ran and the alert for when it did not.

[BullMQ monitoring](https://logdash.io/cron-monitoring/bullmq): Use Bull Board or Taskforce.sh to see queues and jobs, and add a 10-second job scheduler that pings a Logdash push monitor so you are told when workers stop processing.

[Kubernetes CronJob monitoring](https://logdash.io/cron-monitoring/kubernetes-cronjob): Kubernetes records when each CronJob last succeeded in status.lastSuccessfulTime and never alerts on it, so either alert on that timestamp in Prometheus through kube-state-metrics, or run a small watcher that pings an external monitor every 10 seconds while it is fresh.

[GitHub Actions monitoring](https://logdash.io/cron-monitoring/github-actions): GitHub shows you the runs that failed but never the runs that did not start, so watch a scheduled workflow from outside: the last step reports success, and a monitor alerts you when that report goes stale.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.