Cron Jobs and Scheduled Tasks in System Design
Time can trigger work, but it does not prove the work finished
A scheduled trigger starts a separate lifecycle
A service needs to produce a daily report, expire old records or send reminders. A schedule decides when to attempt that work. The job itself still needs inputs, progress tracking and a correct result.
Cron is a common recurring scheduling mechanism. Managed schedulers, operating-system timers and platform job controllers offer related capabilities. A scheduled trigger is not a guarantee of exactly one successful run at an exact instant.
What you’ll learn
- Separate trigger time from successful job completion.
- Observe overlapping scheduled runs and a skip policy.
- Plan timezone, retries, missed runs and duplicate-safe effects.
Define the clock and the work window
A traditional cron expression often has minute, hour, day-of-month, month and day-of-week fields. Providers may use different field counts and semantics, so validate the selected scheduler’s format.
State the timezone explicitly. Local daylight-saving changes can create missing or repeated clock times. If a daily report covers a data window, identify that window independently from when the job happens to start.
Missed triggers need a policy: catch up, skip or alert. A restart or maintenance period can delay scheduling, so a job should not assume every previous attempt completed.
Run a 90-second job on a 60-second schedule
See overlapping runs on a timeline
Run 1 starts at 0 s. It lasts 90 s; the next trigger is at 60 s.
Trigger interval 60 s · run duration 90 s · clock advances only on click · only the latest six run cards are shown.
In this model, a run lasts 90 simulated seconds and a trigger occurs at 0, 60, 120 and later multiples of 60. Advance 30 seconds at a time. Allow mode starts every scheduled attempt; skip mode skips a trigger when a prior run is still active.
The skip policy prevents overlap in this one-job model, but skipped periods are not automatically processed later. Time is deterministic here; real controllers may delay, duplicate or miss attempts and may need persisted coordination across replicas.
Make a repeated run safe
A reminder job can send a message and crash before recording success. On retry, the same reminder may be sent again. Use a stable action identifier and a suitable persisted rule, or use an external API’s idempotency feature when it provides the required contract.
For large jobs, record checkpoints and a defined data window so the work can resume. Consider records added while processing, partial failures and how a rerun affects already-processed data.
A distributed lock needs correct lifetime, ownership and failure handling. A lock expiring while a slow worker still runs can allow overlapping effects. A local in-memory flag coordinates only that one process.
Choose a scheduler and observe its outcomes
Operating-system cron may suit a small host-local task if host failure and logs are handled. A platform controller can coordinate container jobs; a managed scheduler reduces some host maintenance but adds service limits, permissions and charges.
Kubernetes CronJob documentation explains schedules, concurrency policy and job considerations. Source checked 6 October 2026. Its controls do not make an arbitrary external effect exactly once.
Track last successful completion, duration, failure count, skipped runs and age of unprocessed work. “The scheduler is running” is weaker than “today’s report completed correctly.”
Check your design decision
Check your design decision
Design the job, not just the expression
Specify timezones, data windows and missed-run behaviour. Observe completion rather than only triggers.
Handle overlap, retries and partial progress with rules appropriate to the job’s effects. Test restarts and delayed runs before relying on the schedule.
Reaching the recap and completing the quizzes are separate milestones.