Scheduling Recurring Work
A CronJob is a controller that creates Jobs on a time-based schedule. It's the Kubernetes equivalent of a Unix cron daemon — you define a schedule in standard cron format, a concurrency policy, how many past Job records to retain, and a Job template underneath it; at each scheduled time, the CronJob creates a Job object from that template, which then runs the task to completion.
Cron Schedule Format
The schedule field uses standard Unix cron syntax with five fields:
┌───────────── minute (0–59)
│ ┌───────────── hour (0–23)
│ │ ┌───────────── day of month (1–31)
│ │ │ ┌───────────── month (1–12)
│ │ │ │ ┌───────────── day of week (0–6, Sunday=0)
│ │ │ │ │
* * * * *
Common examples:
| Schedule | Meaning |
|---|---|
0 2 * * * |
Daily at 2:00 AM |
*/15 * * * * |
Every 15 minutes |
0 9 * * 1 |
Every Monday at 9:00 AM |
0 0 1 * * |
First day of every month at midnight |
The concurrencyPolicy Field
This field controls what happens if a scheduled Job is still running when the next scheduled time arrives:
Allow(default): Start the new Job even if the previous one is still running. Risk: multiple instances running simultaneously.Forbid: Skip the new Job if the previous one is still running. Risk: missed executions if jobs consistently run long.Replace: Cancel the currently running Job and start a new one. Risk: incomplete work from the cancelled job.
For most backup or report jobs, Forbid is the safest choice — you'd rather miss a scheduled run than have two backup jobs writing to the same destination simultaneously.
A common interview question: "How do you ensure a CronJob doesn't run concurrently with itself?" The answer is concurrencyPolicy: Forbid. A follow-up question is often: "What's the risk of using Forbid?" Answer: If a job consistently takes longer than its schedule interval, executions will be skipped indefinitely. You should monitor job duration and alert if it approaches the schedule interval. Also set activeDeadlineSeconds on the Job template to kill runaway jobs automatically.