// enter a cron string and see the next 10 scheduled run times
Enter a cron expression and instantly see the next 10 scheduled run times with human-readable explanations. Free, browser-based, no sign-up required.
| Field | Range | Special |
|---|---|---|
| Minute | 0–59 | * , - / |
| Hour | 0–23 | * , - / |
| Day of month | 1–31 | * , - / ? |
| Month | 1–12 | * , - / |
| Day of week | 0–7 (0,7=Sun) | * , - / |
Enter a cron expression
Preview the next 10 scheduled run timesType your cron string in the input field, or click one of the quick preset buttons above.
Select your target timezone. Optionally set a start date to preview runs from a specific point in time.
Click "Preview Next Runs" to instantly see the schedule with human-readable explanation and precise timestamps.
The Cron Expression Tester parses standard 5-field cron expressions and computes the next 10 future scheduled times. Each run is shown with its exact date, time, and relative distance from now — helping you verify your schedule is correct before going live.
Supports all standard cron features: step values (*/5), ranges (1-5), lists (1,3,5), and named shortcuts like @daily, @weekly, @monthly, and @hourly.
A cron expression is a string of 5 fields separated by spaces that defines a recurring schedule: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–7, where 0 and 7 both mean Sunday). For example, 0 9 * * 1-5 means "at 9:00 AM every weekday."
* means "every value," , separates multiple values (e.g. 1,3,5), - defines a range (e.g. 1-5), and / defines a step (e.g. */15 = every 15 units). Most standard cron implementations support all four.
Yes. This tool supports common cron shortcuts: @hourly (0 * * * *), @daily (0 0 * * *), @weekly (0 0 * * 0), @monthly (0 0 1 * *), and @yearly (0 0 1 1 *).
Cron times are always relative to the server's timezone, which is often UTC. If your cron job runs at unexpected hours, make sure to account for timezone offset. Use this tool with the correct timezone selected to preview actual local run times.
Standard Unix cron uses 5 fields (no seconds). Some systems like Quartz Scheduler or AWS EventBridge use 6-field expressions with seconds. This tool supports the standard 5-field format used by Linux crontab, GitHub Actions, and most cloud schedulers.
*/15 means "every 15 units of that field." In the minutes position, */15 means every 15 minutes (at :00, :15, :30, :45). In the hours position, */2 would mean every 2 hours.
Yes. Use the "Start From" field to set a custom starting point. The tool will then calculate the next 10 run times starting from that date and time, which is useful for testing year-end, leap year, or month-boundary edge cases.
Yes — fully free, browser-based, and no sign-up required. All cron parsing runs client-side in JavaScript. No expression data is sent to any server, making it safe for internal schedule logic and production cron strings.
A cron expression tester is a developer tool that parses a cron schedule string and calculates the exact future run times based on it. Instead of waiting for your server to execute the job or reading through documentation to mentally compute the schedule, a tester does the work instantly — showing you the next 10 (or more) scheduled executions in real time.
This is especially useful when writing or debugging cron jobs for Linux servers, GitHub Actions workflows, AWS Lambda scheduled events, Google Cloud Scheduler, Kubernetes CronJobs, and any other system that accepts the standard cron format.
Every standard cron expression consists of exactly 5 fields separated by spaces. Each field controls a different unit of time:
30 = at :30, */10 = every 10 minutes.0 = midnight, 13 = 1 PM.1 = first of month, 15 = fifteenth.* = every month, 1,7 = January and July.1-5 = Monday through Friday.Cron expressions support several special characters that make schedules flexible and powerful:
* — Wildcard: matches every value in the field. * * * * * runs every single minute., — List: separates multiple values. 0,30 in minutes = at :00 and :30 each hour.- — Range: defines an inclusive range. 9-17 in hours = from 9 AM to 5 PM./ — Step: combined with ranges or wildcard. */5 = every 5 units. 10-50/10 = 10, 20, 30, 40, 50.Here are some of the most frequently used cron schedules:
* * * * * — Every minute, every hour, every day0 * * * * — At the top of every hour0 0 * * * — Every day at midnight (UTC)0 9 * * 1-5 — Every weekday at 9:00 AM*/15 * * * * — Every 15 minutes0 0 1 * * — First day of every month at midnight0 0 * * 0 — Every Sunday at midnight30 6,18 * * * — At 6:30 AM and 6:30 PM daily0 2 * * 6,0 — Saturday and Sunday at 2:00 AM0 0 1 1 * — Once a year, January 1st at midnightMany cron implementations support predefined scheduling shortcuts that make common schedules easier to read and write:
@hourly — Same as 0 * * * *@daily or @midnight — Same as 0 0 * * *@weekly — Same as 0 0 * * 0 (Sunday midnight)@monthly — Same as 0 0 1 * * (first of month)@yearly or @annually — Same as 0 0 1 1 *One of the most common sources of confusion with cron jobs is timezone handling. Cron on Linux servers runs in the server's local timezone, which is often set to UTC. If you schedule 0 9 * * * expecting it to run at 9 AM New York time, but your server is in UTC, the job will actually run at 5 AM New York time during EST, or 4 AM during EDT.
Cloud platforms handle this differently. AWS EventBridge and Google Cloud Scheduler allow you to specify timezone directly. Kubernetes CronJobs use the cluster's timezone. GitHub Actions always runs in UTC. This tool lets you select your timezone so you can preview what the actual local execution times will look like.
One of the most expensive mistakes in backend development is deploying a cron job with a wrong schedule — running too frequently (causing server overload or cost spikes) or too infrequently (causing stale data, missed reports, or delayed notifications). Testing your cron expression before deployment takes seconds and can prevent hours of production debugging.
Use this tester to verify edge cases: Does your monthly job handle February correctly? Does your "weekday" schedule correctly exclude weekends? Does your "every last day of month" logic work in months with 28, 29, 30, and 31 days? Preview the next runs to confirm behavior before pushing to staging or production.
The cron syntax is largely standardized, but platform-specific variations exist. Linux crontab (man 5 crontab) is the original standard. Vixie cron, the most common implementation, supports all 5 fields plus named shortcuts. AWS EventBridge supports cron with a 6-field format where the first field is minutes (not seconds) and includes year as a 6th field. Quartz Scheduler (Java) uses 6 or 7 fields with seconds. GitHub Actions uses standard 5-field UTC cron.
This tool focuses on the standard 5-field format compatible with Linux crontab, GitHub Actions, Heroku Scheduler, and most major cloud scheduler services.