Kubernetes cronjob not triggering: schedule debugging

TL;DR

A CronJob that never triggers is usually suspended, has a schedule that does not mean what you think, or is blocked by concurrency and deadline settings. Check suspension first, validate the cron expression against what you intended (timezones bite), then look at the controller. Jobs that start but fail are a different problem.

The query

Kubernetes cronjob not triggering: schedule debugging

Use this when

• A CronJob creates no jobs at all
• The schedule fires at unexpected times
• A previously working CronJob stopped after an upgrade
• You are setting up scheduled tasks for the first time

Not for when

• Jobs that start but fail or crash (debug the job, not the schedule)
• One-off manual runs (use job creation directly)
• External schedulers (Airflow, etc.)

Steps

Step 1: Check whether the CronJob is suspended

Describe the CronJob and look at the suspend field. Suspended CronJobs never trigger, and suspension is easy to set accidentally (or leave on after maintenance). This is the most common cause. Expected output: suspend is false, or you found it true and can unsuspend.

Step 2: Validate the cron expression

Read the schedule field and verify each field means what you intended. Common traps: day-of-month vs day-of-week semantics, and the cluster's timezone vs your timezone (CronJobs run in the controller's timezone unless timeZone is set). Expected output: the expression unambiguously matches the intended times; set timeZone explicitly to remove doubt.

Step 3: Check lastScheduleTime and active jobs

Describe the CronJob and check lastScheduleTime: if it is recent, the CronJob is triggering and the problem is downstream. Also check the active jobs list; a stuck active job plus concurrencyPolicy Forbid blocks all future runs. Expected output: either a recent lastScheduleTime (look downstream) or a stale one (keep debugging the trigger).

Step 4: Look at startingDeadlineSeconds

If the schedule was missed by more than startingDeadlineSeconds (for example the controller was down), that run is skipped silently and counted as a miss. Short deadlines plus controller restarts equal mysteriously skipped runs. Expected output: the deadline setting understood; lengthen it if legitimate delays should not skip runs.

Step 5: Check the cronjob controller itself

If nothing else explains it, check the kube-controller-manager logs for errors reconciling the CronJob. After cluster upgrades, controller bugs or API changes can stall scheduling silently. Expected output: controller errors naming the problem, or a clean bill of health pointing back at config.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bXG7BEeoTou0gt7abmBTbQ