What order are the cron fields in?

Minute, hour, day of month, month, day of week. The frequent mistake is reading the first field as an hour, which shifts everything by one position and produces a schedule that looks reasonable and is wrong.

Why does my job run more often than I expected?

Most likely you restricted both day of month and day of week. When both are set, cron fires when either matches rather than when both do. Set one to a wildcard unless you genuinely want the union.

Every fifth value in that field, counted from its start. In the minute field it is every five minutes. Note it counts from zero rather than from now, so it fires at the multiples of five rather than five minutes after you deployed.

What timezone does cron use?

The timezone of the machine running it, unless the scheduler says otherwise. This is a routine source of jobs running an hour out twice a year, and a reason to prefer UTC on servers.

A crontab.guru alternative that can also run the schedule

crontab.guru is close to perfect at the job it does, it is free, it needs no account, and this page is not going to argue that it is worse. The difference is what happens after you have understood the expression, which on a reference site is nothing.

Open the Cron Parser →

crontab.guru and Softland, side by side

	crontab.guru	Softland
Plain-English reading	Yes, updated as you type	Yes
Next fire times	Shown	Shown
Linking an expression to a colleague	The expression lives in the URL	Not offered
Actually running something on the schedule	Out of scope	A scheduled webhook, on the same site
The day-of-month and day-of-week trap	Visible in the reading	Called out explicitly

The field everyone gets wrong is the fifth one

Cron reads five fields: minute, hour, day of month, month, day of week. The trap is the relationship between the third and the fifth. If both are restricted - a day of month and a day of week both set to something other than a wildcard - cron runs the job when either matches, not when both do. It is the one place in the syntax where the operator is OR rather than AND, and nothing in the expression hints at it.

So an expression meaning the first of the month and also every Monday is a schedule that fires far more often than the person who wrote it intended. It is the most common cause of a job that runs more often than expected, and it is invisible unless something tells you the actual next few fire times rather than the intent you had in mind.

Reading the next times is the only real check

A plain-English rendering tells you what the expression says. The list of upcoming fire times tells you what it does, which is the same thing right up until it is not. Step values interacting with ranges, a range that wraps, a day-of-week number that means Sunday in one implementation and Monday in another - these all read plausibly and behave differently.

Check the dates rather than the sentence. If the next five occurrences are the ones you expected, the expression is right regardless of how it parses in your head; if they are not, you have found the bug before it found you at three in the morning.

Understanding a schedule and having one are different problems

Most people arrive at a cron parser because they are writing a crontab or a CI schedule. Some arrive because they want something to happen on a schedule and cron syntax is simply the notation they have been handed - and for those, understanding the expression is a step rather than the destination.

That second case is why this sits next to a scheduled webhook rather than standing alone. Work out the expression, then give it a URL to call, and the schedule becomes a thing that runs rather than a thing you now have to find a server for.

When crontab.guru is the better choice

You want to send someone an expression to look at - the expression living in the URL makes that a single link, and this has no equivalent.
You want the field-by-field breakdown that names each position as you edit it.
You are already there, which is the honest reason most people use it and a perfectly good one.

Frequently asked questions

What order are the cron fields in?: Minute, hour, day of month, month, day of week. The frequent mistake is reading the first field as an hour, which shifts everything by one position and produces a schedule that looks reasonable and is wrong.
Why does my job run more often than I expected?: Most likely you restricted both day of month and day of week. When both are set, cron fires when either matches rather than when both do. Set one to a wildcard unless you genuinely want the union.
What does */5 mean?: Every fifth value in that field, counted from its start. In the minute field it is every five minutes. Note it counts from zero rather than from now, so it fires at the multiples of five rather than five minutes after you deployed.
What timezone does cron use?: The timezone of the machine running it, unless the scheduler says otherwise. This is a routine source of jobs running an hour out twice a year, and a reason to prefer UTC on servers.

Try it yourself

Explain a cron expression in plain English.

Open the Cron Parser

crontab.guru is a trademark of its respective owner. Softland is not affiliated with, endorsed by or sponsored by crontab.guru. This comparison reflects how each product works rather than what either costs, because pricing and plan limits change; check crontab.guru’s own site for its current terms.