How do I test a Kubernetes CronJob schedule before kubectl apply?

Copy your CronJob's spec.schedule value (e.g., "*/15 9-17 * * 1-5"), paste it into PDFFlare's cron expression tester, and set the timezone to whatever your CronJob's spec.timeZone is set to (or UTC if you didn't set it — that's the cluster default). The tester shows a plain-English description plus the next 5-50 fire times. If those don't match your intent, fix the schedule before applying. Catching a bad schedule pre-apply takes 10 seconds; fixing one in production after it floods logs takes much longer.

What's spec.timeZone in a Kubernetes CronJob and when do I need it?

spec.timeZone (added in Kubernetes 1.27, GA in 1.30) lets you specify an IANA timezone name (e.g., "America/New_York", "Asia/Tokyo") for interpreting the cron schedule. Without it, the schedule runs in UTC. Set it whenever your job's schedule is meaningful in a specific business timezone — payroll runs at 9 AM EST, EU GDPR reports at midnight CET, end-of-day Tokyo close at 5 PM JST. Common mistake: setting spec.timeZone on a cluster running an older Kubernetes version that ignores the field — the job silently runs in UTC and fires at the wrong hour.

Why is my Kubernetes CronJob not firing?

Four common causes: (1) Timezone mismatch — schedule is correct in your local TZ but the cluster runs UTC. Use PDFFlare's tester to verify the next fire time is what you expect. (2) startingDeadlineSeconds expired — if the controller misses the start window (cluster restart, control-plane outage), past-deadline runs are skipped. Either remove the field or set it to a generous value like 600. (3) suspend: true is set on the CronJob spec — kubectl describe cronjob will show this. (4) The job is firing but pods can't schedule due to resource constraints — kubectl get events shows FailedScheduling.

Does Kubernetes CronJob use standard cron syntax?

Yes — Kubernetes CronJob uses standard 5-field cron syntax (minute, hour, day-of-month, month, day-of-week). No seconds field (unlike Quartz/Spring), no year field. Macros like @hourly, @daily, @weekly, @monthly, @yearly are accepted. Day-of-month plus day-of-week is OR (union), not AND — "0 0 1 * 1" fires on every 1st of the month AND every Monday, not just the first Monday. AWS EventBridge supports a "?" placeholder in those fields; Kubernetes does not. PDFFlare's tester validates against standard 5-field syntax.

What's the difference between concurrencyPolicy: Allow vs Forbid vs Replace?

concurrencyPolicy controls what happens if a previous job is still running when the next scheduled fire time arrives. Allow (default) — start the new job in parallel with the still-running one. Use only if your job is idempotent and overlap is safe. Forbid — skip the new run entirely if the previous one hasn't finished. Common for migrations or cleanup jobs that must not overlap. Replace — kill the running job and start a fresh one. Useful for jobs where only the latest run matters (e.g., data sync where stale runs are wasteful). Default Allow is the most common foot-gun — long-running jobs pile up and exhaust pod limits.

May 8, 202610 min read

Kubernetes CronJob Tester: How to Verify Schedules Before Apply

A misconfigured CronJob is one of the most expensive bugs in modern DevOps. Wrong schedule ships, the job fires every minute on production, your log volume spikes 100x, your Loki/Datadog bill jumps. Or the schedule looks right but uses the wrong timezone and your “3 AM nightly backup” runs in the middle of peak traffic. The fix is a 30-second pre-flight check with a Kubernetes CronJob tester BEFORE kubectl apply.

In this guide you'll learn how to verify a Kubernetes CronJob schedule using PDFFlare's Kubernetes CronJob tester — paste the spec.schedulevalue from your manifest, get plain-English description plus the next 5-50 fire times in any of 23 timezones. The tester supports standard 5-field cron (Kubernetes's syntax), 6-field cron with seconds, and Quartz 7-field expressions for mixed ecosystems. Plus the K8s-specific gotchas: the spec.timeZone trap, the 100-missed-deadline edge case, and why concurrencyPolicy can mask schedule bugs.

What a Kubernetes CronJob Actually Schedules

A Kubernetes CronJob resource creates a Job at every schedule fire. The schedule itself uses 5-field standard cron syntax in the spec.schedule field. As of Kubernetes 1.27 (GA), CronJob also supports spec.timeZone as a string IANA timezone name (e.g., Etc/UTC, America/Los_Angeles,Asia/Tokyo). When timeZone is unset, the schedule runs in the kube-controller-manager's local timezone, which is usually UTC but isn't guaranteed.

Example minimal CronJob YAML:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-backup
spec:
  schedule: "0 3 * * *"
  timeZone: "America/Los_Angeles"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup:1.0
          restartPolicy: OnFailure

The schedule: "0 3 * * *"means “3 AM in the timezone specified by spec.timeZone (or the controller's default if unset).” That's exactly the value you paste into PDFFlare's tester to verify, and exactly where the most common bug lives — "3 AM" in WHICH zone?

How to Use This Kubernetes CronJob Tester (Step by Step)

Open the cron expression tester. Visit /tools/dev/cron-expression-tester.
Copy the spec.schedule value from your CronJob YAML. The value inside the quotes — for the example above, 0 3 * * *.
Paste into the cron expression input. The tester parses immediately and shows the plain-English description in the green “Valid” banner.
Set the Timezone dropdown to match spec.timeZone from the manifest. If spec.timeZone is unset, set the dropdown to UTC (the default for most kube-controller-manager installs). The fire times below now show what the schedule actually fires at in that TZ.
Verify the next 5 fire times.If they match your intent (e.g., 3:00 AM Pacific tonight, 3:00 AM Pacific tomorrow night, etc.), you're safe to kubectl apply. If something looks off, fix the schedule or the timeZone before applying.

Common Kubernetes CronJob Schedule Bugs

How to handle CronJob spec.timeZone correctly

Three common timeZone mistakes. (1) Setting spec.timeZone but writing the schedule in UTC anyway — if spec.timeZone: America/Los_Angeles and you wrote schedule: "0 11 * * *" intending 11 AM UTC, the job actually fires at 11 AM Pacific (which is 7 PM UTC). Use the tester to verify. (2) Using a non-IANA timezone name like "PST" or "EDT" — Kubernetes accepts only IANA names. America/Los_Angeles ✓, Pacific Standard Time ✗. (3) Running on a Kubernetes version < 1.27where spec.timeZone isn't available — you'd need to adjust the schedule's clock value to UTC manually.

How to debug a CronJob that's not firing at all

If the schedule looks right in the tester but the CronJob isn't firing, check these in order: (1) kubectl describe cronjob <name>— look for “CronJob doesn't exist anymore” or schedule parse errors in events. (2) spec.suspend: false (default) — if true, the CronJob is paused. (3) spec.startingDeadlineSeconds gotcha: if you set it too low (e.g., 100s), and the controller missed 100+ schedule deadlines, the CronJob stops firing entirely. Either remove the field (default is no deadline) or unset it and let Kubernetes catch up. (4) Pod-level failures — the CronJob may be firing but creating Jobs that fail and exit fast. Check kubectl get jobs.

How to read CronJob status to verify schedule timing

Once a CronJob is applied, check kubectl get cronjob <name> -o yaml and look at status.lastScheduleTime and status.lastSuccessfulTime. If lastScheduleTime is updating on cadence but lastSuccessfulTime lags or is missing, the schedule is firing but the Job is failing — separate problem from schedule timing. If lastScheduleTime never updates after a full schedule cycle, the schedule itself isn't firing. Cross-reference the timestamp with what PDFFlare's tester predicts as the next fire time for your spec.schedule + spec.timeZone combination — if the tester says the next fire is 14:00 UTC but lastScheduleTime never updated past 08:00 UTC, your timezone interpretation is wrong on the cluster. The tester is your source-of-truth oracle for “what should the controller do here.”

How to validate spec.schedule for restricted environments

Some K8s admission policies (e.g., OPA Gatekeeper, Kyverno) forbid certain schedule patterns — “no schedule fires more often than every 5 minutes,” “no weekend schedules,” etc. Run the schedule through PDFFlare's tester to see the next 50 fire times, spot the cadence, and confirm it complies BEFORE you submit the manifest. The tester runs entirely in your browser — safe to use on schedules from confidential internal infrastructure.

How to convert a cron expression for Kubernetes

Coming from a different scheduler? Most cron expressions are portable across ecosystems, with a few exceptions: AWS EventBridge requires either day-of-month OR day-of-week to be ? (not both as wildcards like Linux cron). Spring/Quartz uses 6 fields with seconds prepended. To migrate to Kubernetes (which uses 5-field standard cron): drop the seconds field if it exists, drop any ? placeholders for *, and verify the converted expression in PDFFlare's cron tester before applying.

CronJob Anti-Patterns the Tester Catches

"Every minute" in production: * * * * *creates a Job every minute, potentially overwhelming the cluster. Verify that wasn't your intent.
Daylight Saving Time gaps: a schedule like 0 2 * * * in a TZ that observes DST will skip a day or fire twice when DST changes. Check the next 50 fire times across DST boundaries.
Day-of-month vs day-of-week OR: 0 0 1 * 1fires on every 1st of the month AND every Monday — most teams writing this intended “first Monday of the month.” Use 0 0 1-7 * 1 instead in standard cron.
Sunday confusion: in cron, Sunday is both 0 and 7. Monday is 1. Common bug: writing 0 0 * * 7 intending Saturday — actually fires Sunday.

Pairing the Tester with Other Tools

Once you've verified the schedule, three follow-up tools matter:

Convert fire times to Unix epoch.The tester has a per-fire-time Epoch button that copies the Unix timestamp. Paste into PDFFlare's Timestamp Converter to verify it lines up with logs from previous runs (compare expected vs observed).
Generate idempotency keys for each fire. Long-running CronJobs benefit from a unique ID per execution to avoid double-processing. Use PDFFlare's UUID Generator (v7 if you want time-ordered, v4 if you don't).
Verify any JWT issued by the job. CronJobs that mint short-lived service tokens can be checked via JWT Decoder — confirm the iat/exp claims match the schedule cadence.

Common Mistakes

Skipping the test entirely.“It looks right” isn't verification. Paste, see the next 5 fire times, then apply.
Testing without setting timeZone in the tester. Default to UTC if your manifest doesn't set spec.timeZone. The tester defaults to your local timezone, which is rarely what the cluster uses.
Setting startingDeadlineSeconds without understanding it. If the controller misses 100+ schedule firings within the deadline window, the CronJob stops firing entirely. Don't set this field unless you know why you need it.
Forgetting concurrencyPolicy. Default is Allow— multiple pods can run simultaneously if a previous run is still going. For jobs that aren't idempotent, use Forbid or Replace.

Privacy: Test Locally

PDFFlare's Kubernetes CronJob tester runs entirely in your browser via the cron-parser + cronstrue libraries — no schedule is uploaded, no manifest is analyzed server-side. Open DevTools → Network and you'll see zero requests during testing. Safe for schedules from production clusters with confidential internal context, air-gapped environments, or regulated-industry deployments where uploading infrastructure config to a third party is forbidden.

Related Tools

Cron Expression Tester — the protagonist of this guide. Standard 5-field cron + Quartz 6-7 field, 23 timezones, plain-English + next fire times.
Timestamp Converter — convert any cron fire time to Unix epoch for comparison against actual run logs from previous CronJob executions.
UUID Generator — mint per-run idempotency keys for CronJobs that need to avoid double-processing.
JWT Decoder — verify token claims issued by scheduled jobs match the expected schedule cadence.

Wrapping Up

A Kubernetes CronJob tester turns a 30-second paste-and-verify into the cheapest insurance you have against production schedule bugs. The cost-benefit math is overwhelming: 30 seconds in a tester versus an hour (or a day) of debugging a misfiring scheduled job in production, plus the log-bill spike, plus the on-call page. Make “paste into the tester” a mandatory step in your CronJob manifest review checklist alongside resources requests/limits and image-tag pinning.

Use PDFFlare's cron expression tester to verify spec.schedule values BEFORE kubectl apply— match the timezone to your manifest's spec.timeZone, confirm the next 5 fire times match your intent, then ship. Free, browser-based, no upload, no account.