The Cron Job That Ran Fine But Did Nothing Useful

I keep seeing the same pattern at companies I work with. Someone sets up a cron job, it runs for months without issues, then one day it breaks and nobody knows until something downstream falls apart.

Last month it was a payment reconciliation job. Runs daily at 6am, pulls transaction data from Stripe, compares it with our records. It stopped running after a server migration — the new server had a different cron setup and the job wasn't included.

For 11 days, reconciliation didn't happen. We only found out when the finance team noticed a discrepancy in the monthly close. By then we had to manually reconcile 11 days of transactions across two systems.

The frustrating part: adding monitoring would have taken 5 minutes. A dead man's switch — if the job doesn't check in by 6:30am, send an alert.

# what the crontab should have looked like
0 6 * * * /usr/bin/php reconcile.php && curl -s https://watchcron.com/ping/your-token

That one line at the end — the curl to a monitoring endpoint — would have caught it on day 1 instead of day 11.

I started using WatchCron for this across all our production jobs. Setup is basically: create a monitor, get a URL, append it to your cron command. If the ping stops arriving, you get notified via email/slack/webhook.

The mental shift that helped me: stop thinking of cron as reliable infrastructure. It IS reliable at executing on schedule. But everything around it — the job itself, the server, the dependencies — can fail silently. You need something external watching for that silence.