Photo: free stock photography (Unsplash licence) — see imprint
Why cron quietly fails you
A cron job has no memory, no retries and no visibility. It runs, it fails, nobody notices, and three weeks later an accountant discovers that invoices stopped exporting. The problem was never the script — it was that nothing was watching it.
Make work a unit, not a script
Model each task as a message: 'export invoice 4711'. Put it on a queue. A worker takes it, and either succeeds or fails loudly with the message preserved for a retry. Now a single failure is a single retry, not a lost night.
Idempotency is not optional
A retry must not send the invoice twice. Every job needs a key and a check: have I already done this? Skipping this is how customers receive three copies of the same dunning letter.
Alert on absence, not just on errors
The dangerous failure is silence: the job that stopped being scheduled at all. Alert when an expected run does not happen — a dead-man's switch catches what error monitoring never will.
- Queue + worker beats cron for anything that matters.
- Every job must be idempotent.
- Alert when a run is missing, not only when it errors.
Frequently asked questions
It has no memory, no retries and nothing watching it. It runs, it fails, the output goes nowhere, and three weeks later accounting discovers that invoices stopped exporting. The script was rarely the real problem. The problem is that its failure was invisible, and cron has no opinion whatsoever about that.
Not for everything. A nightly report nobody depends on can stay a cron job forever. Move the work where a missed run costs money or trust: invoice exports, ERP syncs, dunning runs, stock updates. The test is simple — if this stopped silently for three weeks, would anyone notice, and what would that cost? That answer decides, not the technology.
Because a retry ran and the job was not idempotent. Every job needs a key and a check — have I already done this one? — so that running it twice does the work once. Without that, the retry mechanism you added for safety becomes the exact thing that sends three copies of the same dunning letter.
You alert on absence. The dangerous failure is silence: a job that stopped being scheduled throws no error, so error monitoring never fires and every dashboard stays green. A dead man's switch — the run checks in, and you get alerted when it does not — catches precisely the failure nothing else catches.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer