Kubernetes CronJob uses standard 5-field cron. Since v1.27, you can set .spec.timeZone to run schedules in a non-UTC timezone. Generates complete YAML you can kubectl apply -f.
| Expression | What it means | Typical use |
|---|---|---|
*/5 * * * * |
Every 5 minutes | Frequent health checks, queue processing. |
0 2 * * * |
Every day at 2 AM | Nightly backups (low-traffic window). |
0 */6 * * * |
Every 6 hours | Periodic cleanup tasks, data refreshes. |
0 0 * * 0 |
Every Sunday at midnight | Weekly batch processing. |
0 0 1 * * |
First of every month | Monthly rotation jobs. |
@daily |
Macro: every day at midnight | Convenient shorthand. |
Click any expression to load it into the tool above.
In Kubernetes v1.27+, add spec.timeZone: "America/New_York" at the CronJob spec level. Older clusters: run the cron in UTC and convert mentally, or use a sidecar that handles the timezone.
Three common causes: (1) the controller is rate-limited (check kube-controller-manager logs), (2) spec.startingDeadlineSeconds is too small and the missed run was abandoned, (3) spec.concurrencyPolicy is Forbid and a previous run is still active.
Job runs once. CronJob creates Job objects on a schedule. You can think of CronJob as a Job factory that fires based on its cron expression.
kubectl get jobs --selector=cronjob.kubernetes.io/name=my-cronjob. CronJob keeps recent Jobs around (controlled by successfulJobsHistoryLimit and failedJobsHistoryLimit, default 3 and 1).
Yes: kubectl create job --from=cronjob/my-cronjob manual-run-001 creates a one-off Job from the CronJob's template.