Cron overlap: locks and idempotent job design

Compare frequency with runtime

An every-minute schedule does not wait for the previous job to finish. A 90-second task can overlap with its next scheduled run.

Use Cron Parser to see triggers and measure runtime separately; the preview cannot tell whether work will complete in time.

Schedule: * * * * *
Run A: 00:00:00 → 00:01:30
Run B: starts 00:01:00 unless overlap is prevented

Choose a concurrency policy

A scheduler may allow overlap, skip a run while one is active, or replace the old run. These policies have different data consequences.

Kubernetes Forbid applies within the same CronJob; it does not provide mutual exclusion across separate CronJobs or unrelated workers.

Build an idempotent effect

A lock reduces concurrent work but does not by itself prevent repeated effects after retries or a crash. Use a stable operation key.

For a scheduled report, combine the job identity with its scheduled instant and enforce uniqueness where the effect is committed.

Operation key: report:2026-11-03T01:00:00Z
Retries reuse this key; they do not generate a new UUID.

Treat lock lifetime as a failure mode

A process can die while holding a lock, or continue after a lease expires. Define lease renewal, ownership and stale-worker handling.

Test a task exceeding its expected duration and a crash after committing output. Cron syntax cannot solve those execution guarantees.