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.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer