Cron Next Run Time Calculator
Enter a 5-field cron expression to see its next 10 run times in UTC and your local timezone — computed instantly in your browser.
Cron expression syntax
| Field | Range | Special chars & example |
|---|---|---|
| Minute | 0–59 | * , - / Example: */15 fires every 15 minutes; 0,30 fires at :00 and :30. |
| Hour | 0–23 | * , - / Example: 9-17 fires every hour from 09:00 through 17:00; */2 fires every other hour starting at 00:00. |
| Day of month | 1–31 | * , - / Example: 1,15 fires on the 1st and 15th; */5 fires on days 1, 6, 11, 16, 21, 26, 31 (where the month has them). |
| Month | 1–12 | * , - / Example: 1,7 fires only in January and July; 3-5 fires in March, April, and May. |
| Day of week | 0–7 (both 0 and 7 represent Sunday) | * , - / Example: 1-5 fires Monday through Friday; 1,3,5 fires Monday, Wednesday, and Friday. |
How to read your next run times
The next-runs table shows the upcoming scheduled fire times for your cron expression in two columns: UTC and your selected local timezone. UTC is the canonical reference — it never shifts for daylight saving time, so it is what the scheduler actually uses internally. Your local-time column is a convenience conversion so you can sanity-check that a job fires at 09:00 on Tuesday morning in your region rather than at an unexpected hour. When you share a cron expression with a colleague in a different timezone, the UTC column is the only unambiguous reference between you.
The same five-field cron expression fires at a different wall-clock time depending on which timezone the scheduler is configured to use. For example, "0 9 * * *" means "when the clock in the scheduler's timezone reads 09:00" — not 09:00 everywhere on Earth simultaneously. If your CronJobPro job is set to Europe/Bucharest (UTC+3 in summer), that job fires at 06:00 UTC. A colleague whose job uses America/New_York (UTC-4 in summer) with the same expression fires at 13:00 UTC. Neither is wrong; they just describe different moments. The next-runs widget makes this concrete by listing the actual UTC timestamps so you can verify the scheduler will do what you intend.
The relative countdown column ("in 4 h 12 m") is the fastest way to debug a misfiring job. If you expect a job to run soon but the countdown shows 23 hours, your expression probably has a day-of-week or day-of-month constraint you forgot about. If the countdown shows a time in the past, your expression may be invalid or the scheduler may be paused. Comparing the absolute UTC time against your server logs pinpoints whether a job fired on schedule and was slow, or never fired at all. Use the countdown as a quick smoke-test; use the UTC timestamp as the ground truth when writing incident reports or correlating with external service logs.
Common cron patterns
* * * * *Every minute — fires once per minute, every hour, every day. Useful for high-frequency polling jobs; be careful about execution time overlap.
*/5 * * * *Every 5 minutes — fires at :00, :05, :10, and so on. A common interval for lightweight health checks or metric collectors.
0 * * * *Every hour on the hour — fires at 00:00, 01:00, 02:00, etc. Good for hourly report generation or cache warming.
0 9 * * *Every day at 09:00 in the scheduler's configured timezone — typical for daily digest emails or morning data imports.
0 0 * * *Every day at midnight — fires once per day at the start of each calendar day in the scheduler's timezone. Often used for daily database snapshots.
0 9 * * 1-5Weekdays at 09:00 (Monday through Friday) — skips Saturday and Sunday. Suitable for business-hours-only jobs like sending invoices or syncing with ERP systems.
0 0 * * 0Every Sunday at midnight — fires once per week. Common for weekly cleanup tasks, report archiving, or low-priority batch jobs.
0 0 1 * *First day of every month at midnight — fires once per month on the 1st. Used for monthly billing runs, subscriber renewals, or monthly rollup reports.
0 0 28-31 * *Days 28 through 31 at midnight — approximates end-of-month; note that not all months have 30 or 31 days, so this fires multiple times in longer months. For true last-day logic, handle the date check inside your job script.
0 */6 * * *Every 6 hours — fires at 00:00, 06:00, 12:00, and 18:00. Common for incremental data syncs or periodic cache invalidation.
30 8 1 1 *Once a year on January 1st at 08:30 — useful for annual tasks like generating a full-year archive, resetting yearly counters, or sending a new-year notification.
0 2 * * 6Every Saturday at 02:00 — fires once per week in the early morning on a low-traffic day. A practical window for database maintenance, index rebuilds, or dependency updates.
Frequently asked questions
What is a cron expression?
A cron expression is a compact string of five space-separated fields that describes a repeating schedule: minute, hour, day-of-month, month, and day-of-week. Each field specifies which values in its range should trigger the job. The scheduler evaluates the expression once per minute and fires the job when the current time matches all five fields simultaneously. The format originated in the Unix cron daemon and is now the de-facto standard for scheduled tasks across Linux, cloud platforms, and job scheduling SaaS tools.
How do I know exactly when my cron job will run next?
Paste your expression into the calculator above. It evaluates the expression against the current time and lists the next several fire times in both UTC and your local timezone. Check the UTC column against your server logs or the job's last-run timestamp to confirm the scheduler is operating as expected. If you need to verify scheduling behavior in a specific timezone, change the timezone selector before running the calculation.
Does timezone affect the cron expression syntax itself?
No. The five-field cron syntax is timezone-neutral — the fields always mean the same thing regardless of where you are. Timezone only affects how the scheduler interprets the hour and minute fields against the local clock. The expression '0 9 * * *' always means 'fire when the hour field is 9 and the minute field is 0.' Whether that corresponds to 09:00 in Bucharest or 09:00 in Tokyo depends entirely on the timezone configured for that specific job in your scheduler.
What does */ mean in a cron field?
The slash character denotes a step value. '*/' means 'every N units across the full allowed range of this field.' So '*/15' in the minute field means 'every 15 minutes starting from 0,' producing matches at 0, 15, 30, and 45. You can also use a range with a step: '10-50/10' in the minute field means 'every 10 minutes, but only between minute 10 and minute 50,' firing at 10, 20, 30, 40, and 50. Steps do not wrap around; they start from the beginning of the range and increment until the range is exhausted.
Why is my cron job not running at the time I expected?
The most common causes are: (1) timezone mismatch — your job is scheduled in UTC but you are reading the clock in a local timezone that differs; (2) a day-of-week or day-of-month constraint you overlooked, such as forgetting that '0 9 * * 1' only fires on Mondays; (3) the job ran but failed silently and you are waiting for a success indicator that never came; (4) execution time of a previous run overlapped with the scheduled start and your scheduler skips concurrent runs by default; (5) your expression has an out-of-range value that the parser accepts but never matches. Paste the expression into the calculator and inspect the next-run times — if they match your intention, the issue is in execution rather than scheduling.
What is the difference between a 5-field and a 6-field cron expression?
Standard Unix cron uses five fields: minute, hour, day-of-month, month, day-of-week. Some systems — notably AWS EventBridge, many Java schedulers like Quartz, and some Kubernetes CronJob implementations — use a six-field format that prepends a seconds field or appends a year field. A six-field expression like '0 0 9 * * ?' (seconds, minutes, hours, day-of-month, month, day-of-week) is not valid in a standard five-field parser and will either error or be misinterpreted. Always check which format your specific scheduler expects before copying an expression from another source.
Can I use expressions from this calculator for AWS EventBridge, Kubernetes CronJobs, or GitHub Actions?
Kubernetes CronJobs and GitHub Actions both use the standard five-field Unix cron format, so expressions from this calculator work directly. AWS EventBridge uses a six-field format with an added seconds field and a mandatory year field, and it uses '?' instead of '*' for the day fields when one is unspecified — so you will need to convert a five-field expression before using it in EventBridge. For example, the five-field '0 9 * * ?' is not valid EventBridge syntax; the equivalent is 'cron(0 9 * * ? *)'. Always validate the expression inside the target platform's own console after converting.
Run this schedule automatically
CronJobPro executes your cron schedule and alerts you the moment a run fails or never happens.