Scheduled Jobs

A scheduled job is unattended by design — nobody watches it fire, which means nobody notices when it stops firing, fires twice, or fires at the wrong time until the downstream effect shows up days later as a data gap or a stale report. Every property that makes cron convenient (fire-and-forget) is also what makes it dangerous without deliberate guardrails.

Design a scheduled job assuming nobody is watching it run — because nobody is, until it breaks.

For cron syntax, DST pitfalls, locking, and Kubernetes CronJob settings, read references/cron-patterns.md.

1. Make the job idempotent, not just retry-friendly

A scheduler that fires a job that's already running, or re-fires after a timeout that wasn't actually a hang, needs the job itself to tolerate a duplicate execution. This is the same idempotency discipline from scripting-automation, but scheduled jobs need it more: nobody is present to notice a duplicate run happened.