Your nightly billing sync ran at 2am. Sidekiq shows it completed. No exceptions, no retries, no dead queue entries. Your app looks healthy. It processed zero invoices. It's been doing this for eleven days. This happens more than people admit. Sidekiq is excellent at handling failed jobs — its retry mechanism and dead queue are genuinely well designed. But "failed" in Sidekiq means "raised an exception." A job that connects to the database, queries 0 rows, and exits cleanly isn't a failed job. It's a successful job that did nothing. Sidekiq has no opinion on the difference. This article covers how to close that gap. Why Sidekiq's built-in monitoring isn't enough for scheduled jobs Sidekiq ships with a web UI that shows queue depths, processed counts, failed jobs, and scheduled jobs. For a queue-based system, this is useful. But for scheduled jobs — the kind you run with sidekiq-cron or sidekiq-scheduler — you need something different. The questions that matter for scheduled jobs are: Did it run on schedule?…