Your cron job last ran successfully when?

Cron is the oldest piece of infrastructure still running in production, and it is also the quietest. When a cron job fails, nothing happens. No alert fires, no dashboard turns red, no page goes out at 3am. The job simply stops doing its work, and you find out weeks later when a backup is missing, an invoice never went out, or a cache table has grown to nine gigabytes. This is the exact anxiety that pushed Sigabrt.dev to the front page of Hacker News, where developers spent an entire comment thread trading stories about jobs that had been silently dead for months.

The existing solutions all ask for something before they give you anything. Healthchecks.io and Cronitor are excellent, but they require you to edit every single cron line to add a heartbeat ping — which means touching production configs you may not own. Sigabrt.dev takes a smarter approach with an SSH TUI, but it still needs SSH access and a process running somewhere. Uptime Kuma needs a server and ongoing maintenance. Every one of these tools assumes you have already decided that cron monitoring is worth the setup cost. Most teams never get that far, because they cannot see the problem yet.

That is the gap. Before you buy a monitor, you need to know whether your crontab is actually at risk. A five-line crontab with proper output redirection and flock guards is fine. A forty-line crontab full of bare commands, hardcoded paths, and * * * * * schedules with no concurrency protection is a time bomb. CronRoast is a static analyzer that reads your crontab the way a senior sysadmin would, flags the patterns that lead to silent failure, and tells you in plain language which jobs