Managing Sidekiq in Production: Scheduled Jobs, Debugging and Cleanup

Sidekiq is easy to get running and easy to lose track of once a Rails app has been in production for a couple of years and forty different job classes. A few practices keep it manageable long after the initial setup.

Queues by priority, not by feature

A common mistake is naming queues after features (invoices, emails, exports) without thinking about what happens when one of them backs up. We organize queues by how urgently they need to run instead: critical for anything a user is actively waiting on, default for everything else, low for exports and reports that can wait an hour. Workers are weighted to drain critical first, so a burst of report generation never delays a password reset email.

-q critical,5 -q default,2 -q low,1

Scheduled jobs need their own visibility

A recurring job that silently stops firing is one of the hardest failures to notice, because nothing errors, nothing pages, things just quietly stop happening. We pair every scheduled job with a heartbeat check: the job pings a monitoring endpoint on success, and an alert fires if that ping doesn't show up within its expected window.

Dead jobs are a queue, not a graveyard

The dead set fills up quietly and gets ignored until someone notices a customer never received an invoice from three weeks earlier. We review it on a schedule, not just when someone complains, and we treat a job that dies repeatedly as a signal that either the job or its retry count needs to change, not something to just requeue and forget again.

Memory bloat is usually one job's fault

A worker process slowly growing in memory until it gets killed is almost always caused by one specific job loading too much into memory at once, an unbatched query loading an entire table being the most common culprit. Batched loading with a sane page size fixes the majority of these, and a memory-per-job metric in your monitoring makes the culprit obvious instead of a mystery.