How to Read a Cron Expression

The standard order is minute, hour, day of month, month, and day of week. In 30 6 * * 1-5, the minute is 30, the hour is 6, both calendar fields use every allowed value, and the final field limits runs to Monday through Friday. That means 6:30 on weekdays.

An asterisk means every value in that field. A comma lists values, a hyphen gives a range, and a slash gives a step. For example, */15 in the minute field means every 15 minutes, while 9-17 in the hour field covers hours 9 through 17.

The tool also accepts a sixth leading seconds field. When six fields are present, the order starts with second and then continues with minute, hour, day of month, month, and day of week. Do not paste a six-field expression into a system that only accepts five fields.

* * * * * runs every minute. */5 * * * * runs every five minutes. 0 * * * * runs at minute zero of every hour. 0 0 * * * runs daily at midnight, based on the time zone used by the scheduler.

0 9 * * 1-5 runs at 9:00 on weekdays. 0 0 * * 0 runs at midnight on Sunday. 0 0 1 * * runs on the first day of each month, and 0 0 1 1 * runs on January 1 each year.

The explainer includes presets named Every minute, Every 5 minutes, Hourly, Daily at midnight, Weekdays at 9:00, Weekly (Sunday), Monthly (1st), and Yearly (Jan 1). Presets are useful starting points, but compare the final expression with the exact operating requirement.

Use a complete expression without shell commands, log paths, or surrounding configuration syntax. The explainer supports standard five-field cron, an optional leading seconds field, and common macros such as @hourly, @daily, @weekly, @monthly, and @yearly.

The third field is day of month, while the fifth field is day of week. 0 8 15 * * refers to the 15th day of each month. 0 8 * * 1 refers to Monday. The similar positions are a frequent source of schedules that run on the wrong dates.

Be extra careful when both fields contain restrictions. Cron implementations can differ in how day-of-month and day-of-week conditions interact. Some treat them as alternatives when both are set. Read the documentation for the actual scheduler rather than assuming behavior from a generic explanation.

Names such as MON and JAN may be accepted, and the explainer can describe named months and days. Numeric day-of-week values commonly use 0 or 7 for Sunday, but platform conventions still deserve checking. Porting a schedule between systems is a reason to test the next dates again.

A cron expression contains clock fields but usually does not contain a time zone. The scheduler supplies that context. A job configured for 9:00 UTC will not run at 9:00 local time in most locations, and the local difference may change during daylight-saving transitions.

The tool initially uses your browser's resolved local time zone. Show UTC recalculates the next five runs in UTC. Match that switch to the environment where the job runs, not merely the time zone of the person reviewing it. Cloud services and container platforms often document a default zone.

If you need to compare a logged Unix time with a scheduled run, the Timestamp Converter can show a timestamp as a readable date in a chosen zone. Also check month ends, weekends, daylight-saving changes, and dates near deployment so a plausible schedule does not hide a boundary error.

Five fields mean minute, hour, day of month, month, and day of week. Six fields are read with seconds first. The explainer validates the expression, gives a sentence, breaks down the fields, and calculates five upcoming run times.

The tool does not install a cron job, run commands, inspect a server, or know the scheduler's retry and overlap rules. A valid expression only means the schedule can be parsed. The command, permissions, environment variables, locking, monitoring, and failure handling remain separate concerns.

Before deployment, compare the next five dates in the correct zone and document the intended schedule in ordinary language. After deployment, verify an actual run and alerting behavior. For critical jobs, test with a safe command first rather than waiting for an important production action to reveal a timing mistake.