Cron Expression Parser

The Five Positions That Schedule the World's Automation

Cron has been scheduling Unix jobs since 1975 and remains the backbone of server automation today — backups, report generation, data synchronisation, cache warming, cleanup tasks. Yet its syntax trips up even experienced engineers. Is */5 every 5 minutes or every 5th minute starting from 0? Does the day-of-week field use 0 or 1 for Sunday? Does a job with both day-of-month and day-of-week set to non-wildcards run on days that match either condition or both?

This parser answers all of these questions in real time. Enter any cron expression and get a plain English explanation of each field, a one-sentence summary of the full schedule, and the next 8 run times calculated in your local timezone.

Anatomy of a Cron Expression

A standard cron expression has five space-separated fields. Reading left to right: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or JAN–DEC), day of week (0–7, where both 0 and 7 mean Sunday). Each field can be a specific number, an asterisk for "every value", a range like 1-5, a step like */15, or a comma-separated list like 1,15. A handful of fields and operators produce an enormous range of schedules.

Common Schedule Patterns and What They Mean

• * * * * * — Every minute, all day every day.
• 0 * * * * — Once per hour, at the top of the hour.
• */15 * * * * — Every 15 minutes: :00, :15, :30, :45.
• 0 9 * * 1-5 — 9:00 AM Monday through Friday.
• 0 0 1 * * — Midnight on the first day of each month.
• 0 2 * * 0 — 2:00 AM every Sunday.
• 0 9,17 * * 1-5 — 9:00 AM and 5:00 PM on weekdays.
• 30 23 * * * — 11:30 PM nightly — common for database backups.

The UTC Trap That Burns Server Operators

Production servers typically run in UTC. Developers typically think in their local timezone. The expression 0 9 * * * means 9:00 AM server time — which on a UTC server means 9:00 AM UTC, not 9:00 AM in your city. If you're in India (UTC+5:30), your "9 AM job" runs at 3:30 PM local time. This tool shows run times in your browser's local timezone so you can see exactly when the job will fire from your perspective. For verifying when a job fires relative to events with known timestamps, the Epoch Converter shows the same moment in UTC and local time simultaneously.

Cloud Scheduling vs Traditional Cron

Modern cloud platforms use cron-compatible expressions with minor variations. AWS EventBridge Scheduler and CloudWatch Events add a year field as a sixth position. Spring Boot's @Scheduled and Quartz use a seconds field as the first position. GitHub Actions on.schedule.cron uses standard 5-field cron in UTC. Azure Logic Apps and Google Cloud Scheduler also accept cron-style schedules. This tool parses standard 5-field expressions. If your platform expects a different format, check the field count and consult the platform's documentation.

What to Verify Before Deploying a Scheduled Job

• The next run times in your intended timezone: Use this tool to see the first 8 occurrences and confirm they match your expectations.
• Behaviour across month boundaries: 0 0 31 * * never runs in months with fewer than 31 days. 0 0 29 2 * only runs on leap year Februaries.
• Day-of-week and day-of-month interaction: When both are set, most cron systems use OR logic — the job runs on any day that satisfies either condition.
• UTC vs local time on the target server: Verify the server timezone before deploying, especially for jobs that must run during business hours or at end-of-day.

✓Verified by ToollyX Team · Last updated June 2026