Your cron is lying to you. Here's how to catch silent failures.

#devops #monitoring #production #sre

I found out the hard way that most production apps have zero monitoring on their cron jobs and queue workers. My uptime monitor said everything was fine. It was lying.

What happened

A deploy wiped out our cron entry. The app still returned 200 on every health check. Nobody noticed the scheduler stopped firing. Nightly emails just... stopped.

Three days later, the billing queue had 6,000 jobs backed up. No errors anywhere. No alerts. Just a very confused customer asking why their invoice never arrived.

Generic uptime monitors check if a URL responds. They can't tell you if your cron ran, if your workers are alive, or if your queue is hemorrhaging jobs.

What I built

I got tired of finding out about broken jobs from angry customers, so I built Crontinel. It's open source, and it watches the stuff your uptime monitor can't see.

Here's what it tracks:

Scheduler - did the cron job actually fire? Is it drifting?
Workers - are they alive? Crashed? Stuck paused?
Queue depth - how deep is the backlog? How old is the oldest job?
Agent runs - is that AI agent stuck in a tool call loop burning your API credits?

Setup is two commands, no per-task wrapping:

# Laravel
composer require crontinel/laravel

# Node
npm i @crontinel/node

# Python
pip install crontinel

It hooks into your framework's existing events. No decorators. No middleware changes. No touching your job classes.

What you see

$ crontinel check
✓ scheduler           last run 00:00:12 ago
✓ workers.default     2 supervisors · running
✓ queue.invoices      127 pending · 2m oldest
✓ agents.support      12 runs · p95 8.2s
✗ queue.emails        backpressure · 6,413 pending

That last line tells you something is wrong before your customers do.

You get 60 second detection, per-worker status, alert routing to Slack or PagerDuty or wherever your team hangs out, and a CI/CD check you can throw in your deploy hook.