How do I test a cron expression online for free?

Open PDFFlare's cron expression tester, paste your cron expression, get a plain-English description plus the next 5-50 fire times in any of 23 timezones. The description updates as you type, so you see immediately whether the schedule matches your intent. All parsing runs in your browser via cron-parser + cronstrue libraries — no upload, no signup. Free and unlimited.

Why does my cron job fire at the wrong time?

Almost always a timezone mismatch. Cron schedules don't include a timezone — the runner interprets them in whatever TZ it uses (UTC for most cloud providers like AWS, GCP; local TZ for Linux crontab). Switch the timezone dropdown in PDFFlare's tester to your runner's actual TZ. If your '0 9 * * *' fires at 5 AM your time but the runner is UTC, you needed '0 17 * * *' instead. Common gotcha for engineers debugging cross-timezone scheduled jobs.

Does day-of-month plus day-of-week mean AND or OR?

OR — the union, not the intersection. '0 0 1 * 1' fires on EVERY 1st of the month AND on EVERY Monday — both, not just Mondays that fall on the 1st. This is the single most-misunderstood part of cron syntax. To restrict to 'first Monday of the month' in standard cron, use '0 0 1-7 * 1' (the 1st through 7th matches the first week, intersected with Monday). For more complex patterns, migrate to Quartz cron which supports '1#1' (first Monday of month) syntax.

Is Sunday 0 or 7 in cron expressions?

Both — standard cron treats 0 and 7 identically as Sunday. So '0 0 * * 0' and '0 0 * * 7' fire at the same times. Day-of-week numbering: Sunday = 0 or 7, Monday = 1, Tuesday = 2, ..., Saturday = 6. Common bug: assuming Monday is 0 (it's Sunday) — you'd accidentally schedule jobs for Sundays instead of Mondays. PDFFlare's plain-English description renders weekday names so you can verify at a glance.

Can I test Kubernetes CronJob expressions with this tool?

Yes — Kubernetes uses standard 5-field cron syntax (no seconds, no year). Paste your CronJob's spec.schedule value into PDFFlare's cron expression tester, set the timezone to your cluster's spec.timeZone (or UTC if not set), and verify the next 5-50 fire times match your intent. Run the test BEFORE kubectl apply — wrong schedule on production fires every minute and floods logs. The tester also supports 6-field (with seconds) and 7-field Quartz expressions for Spring/Java schedulers.

May 8, 20269 min read

Cron Expression Tester: How to Test Cron Online (2026)

A good cron expression tester is the fix for almost every schedule debugging session. You wrote 0 9 * * 1-5 and the cron fired at 4 PM. You wrote */15 9-17 * * 1-5 and now you're not sure if that includes 5 PM or stops at 4:45 PM. You wrote 0 0 1 * 1intending “first Monday of the month” — but it's firing every Monday AND every 1st. Cron syntax is densely packed and notoriously easy to read wrong.

In this guide you'll learn how to test a cron expression online using PDFFlare's Cron Expression Tester — paste your expression, get a plain-English description plus the next 5-50 fire times in any of 23 timezones, all live as you type. Plus the three gotchas that catch even experienced devs (timezone, OR-not-AND, and Sunday=0=7), and how to verify a Kubernetes CronJob schedule before kubectl apply.

What Is a Cron Expression?

A cron expression is the standard syntax Unix uses to define recurring schedules. Five fields separated by spaces, plus optional 6th (seconds) and 7th (year) fields for Quartz-style schedulers:

┌─── minute (0-59)
│ ┌─ hour (0-23)
│ │ ┌── day of month (1-31)
│ │ │ ┌── month (1-12 or JAN-DEC)
│ │ │ │ ┌── day of week (0-7 or SUN-SAT, both 0 and 7 = Sunday)
│ │ │ │ │
* * * * *

* = every value
*/N = every Nth value (so */15 in minute = :00, :15, :30, :45)
1-5 = range, inclusive (Mon-Fri in day-of-week)
1,3,5 = list of specific values
@hourly, @daily, @weekly, @monthly, @yearly — shorthand macros

How to Test a Cron Expression (Step by Step)

Open the cron expression tester. Visit /tools/dev/cron-expression-tester.
Paste your cron expression.Or click a preset like “Every 15 minutes” or “Weekday 9 AM” to populate the input.
Read the green plain-English banner. “Every 15 minutes, between 9:00 AM and 5:59 PM, Monday through Friday” is much easier to verify than the raw symbols. If the description doesn't match your intent, edit and watch it update live.
Verify the next fire times.The list shows the next 5 (or 10/25/50) absolute timestamps, with relative-time hints (“in 2 hours”, “tomorrow at 9:00”) so you spot anomalies instantly. Each row has an Epoch button to copy the Unix timestamp for piping into other tools.
Switch timezones.Cron schedules don't embed timezone — switching the dropdown shows what your cron actually fires at in different regions. Critical when your laptop is in PT but the production cron runs in UTC.

Why a Cron Expression Tester Beats Manual Math

Reading cron in your head is doable for simple cases but breaks down quickly: ranges with steps (0-30/5 * * * *), lists across multiple fields (0,15,30,45 * * 1,15 *), and any 6-field Quartz expression with seconds and year. A cron expression tester removes the guesswork — paste it, see the next 5 fire times, decide if it matches intent. Useful as both a cron schedule online debugger AND a cron expression generator (start from a preset, edit one field, copy the result).

The most-used tester for years has been crontab.guru — minimal UI, fast, gets the job done for the simple case. But it's missing four things modern teams need: timezone selector (it always uses your browser's local TZ — hopeless when debugging schedules on UTC servers), Quartz 6-7 field support (so Spring/Java schedulers can't be tested), bulk fire-time count beyond 5, and one-click epoch copy for piping into APIs. PDFFlare's tool is a crontab.guru alternative that adds all four — same paste-and-see-fire-times core, but with the features you need when the schedule isn't firing for the reason you expected.

The Three Gotchas Every Developer Hits

What does this cron run? How to find out fast

Almost always a timezone bug. Cron syntax doesn't carry timezone metadata — the runner interprets the schedule in whatever TZ it was given (or whatever its default is). Most cloud providers default to UTC. Linux crontab uses the server's local TZ. PDFFlare's Cron Expression Tester lets you switch the timezone dropdown to your runner's actual TZ; if your “9 AM” cron fires at 5 AM your time, you found the bug.

Why does day-of-month + day-of-week fire on every match

The single most common cron misunderstanding. When you specify BOTH day-of-month and day-of-week, the schedule fires on the UNION (OR), not the intersection (AND). So 0 0 1 * 1fires at midnight on the 1st of every month AND every Monday — both, not just Mondays that fall on the 1st. To restrict to “first Monday of the month” in standard cron, you need a workaround: 0 0 1-7 * 1matches Monday in the first week. Or upgrade to Quartz which supports “1#1” (first Monday).

How to handle Sunday in cron expressions

In standard cron, day-of-week 0 AND 7 BOTH mean Sunday. Monday is 1, Saturday is 6, Sunday is 0 or 7. So 0 0 * * 0 and 0 0 * * 7are the same schedule. PDFFlare's tester accepts either. Common related bug: thinking Monday is 0 (it's 1 — you'd be firing on Sunday, not Monday).

Testing Cron for Specific Schedulers

How to test a Kubernetes CronJob expression before applying

Kubernetes CronJob uses standard 5-field cron in the spec.schedulefield. Wrong schedule ships, fires every minute on production, floods Loki/Datadog. Paste the CronJob's schedule into the tester BEFORE running kubectl apply. Set the timezone to your cluster's configured TZ (or UTC if you didn't set spec.timeZone) and confirm the next 5 fire times match your intent.

How to test a GitHub Actions cron schedule

GitHub Actions on: schedule:uses 5-field cron in UTC. Common bug: writing the schedule in your local TZ. Always set the tester's timezone to UTC to match GitHub's interpretation. Note that GitHub Actions can be delayed by up to 15 minutes during high load — the schedule is best-effort, not exact.

How to test a Quartz cron expression for Spring schedulers

Spring/Quartz uses 6 or 7 fields: seconds prepended, year optionally appended. 0 0 9 * * 1-5 (6-field) fires Monday-Friday at exactly 9:00:00 AM. The PDFFlare tester accepts 5, 6, and 7-field expressions — paste any and it parses correctly.

How to Debug a Cron That Already Shipped Wrong

The tester is most useful BEFORE you ship a schedule, but it's also the fastest way to diagnose a misfiring production cron. Workflow: pull the live spec.schedule / schedule / * * * * *string from the running config (kubectl, AWS console, GitHub Actions YAML, your orchestrator's UI), paste into the tester, and compare the predicted next 50 fire times against the actual fire times in your job logs.

Three distinct failure modes show up in the diff: (1) Timezone drift— the predicted UTC fire time matches the runner's log time, but you intended local time. Fix: switch the tester's timezone dropdown to UTC, see the actual schedule, then rewrite the cron string for the timezone the runner uses. (2) Day-of-week / day-of-month union surprise — predicted fire times include unexpected days. The OR semantics means 0 0 1 * 1 fires on every 1st AND every Monday, not just the first Monday. Restrict via 0 0 1-7 * 1 or migrate to Quartz cron with 1#1 syntax. (3) DST boundary skipped or doubled— daily schedules near 2 AM in a DST-observing timezone fire twice (fall back) or skip a day (spring forward). Run the tester across the DST date range and watch the fire times — they'll telegraph the problem before production does. The tester's 50-fire-time count is deliberately tuned to span ~2 weeks of a typical schedule so you can spot DST issues, week-vs-month boundary bugs, and end-of-month edge cases (Feb 29, 30/31 day months) in one paste.

Common Cron Expression Patterns

*/5 * * * * — every 5 minutes
0 * * * * — every hour at :00
0 9 * * * — daily at 9 AM
0 9 * * 1-5 — weekdays at 9 AM
0 0 * * 0 — Sundays at midnight (weekly)
0 0 1 * * — first of every month at midnight
0 0 1 1 * — January 1st at midnight (yearly)
*/15 9-17 * * 1-5— every 15 min, 9-5 PM, weekdays (most common “business hours” schedule)

Common Mistakes

Writing schedules in local timewhen the runner uses UTC. Always confirm the runner's TZ before writing.
Using 0 0 1 * 1 for “first Monday” — it fires on every 1st AND every Monday. Use 0 0 1-7 * 1instead, or migrate to Quartz for “1#1” syntax.
Confusing */0 with disabled — */0 is invalid syntax (step of zero). To disable a cron, comment the line out or remove it.
Assuming AWS EventBridge uses standard cron — it uses a 6-field variant where day-of-month and day-of-week can't both be wildcards. Use cron(0 9 ? * MON-FRI *) not cron(0 9 * * 1-5).

Privacy: Test Locally

PDFFlare's cron expression tester runs entirely in your browser via cron-parser and cronstrue libraries. No server is involved, no schedules are uploaded, no logs are kept. Open DevTools → Network and you'll see zero requests while you type or switch timezones. Safe for testing schedules from confidential production infrastructure or air-gapped environments.

Related Tools

Cron Expression Tester — the protagonist. Plain-English + next fire times in any of 23 timezones.
Timestamp Converter — convert each cron fire time to Unix epoch for piping into APIs that expect timestamps.
JWT Decoder — verify token issued-at and expiration claims align with your scheduled job runs.
UUID Generator — mint request IDs for individual scheduled job runs (idempotency keys, log correlation).

Wrapping Up

Test a cron expression online in three seconds with PDFFlare's Cron Expression Tester — paste, read the plain English, verify the next 5-50 fire times. Use it as a kubernetes cronjob tester before applying YAML manifests, a cron next run time calculator when debugging unexpected fires, a crontab generator when starting from a vague requirement, or a cron parser online for quick sanity checks. Free, browser-based, no upload.