# Cron Expression Explainer > Translate any cron expression into plain English and see the next ten runs in your timezone and UTC side by side. Runs entirely in your browser. Source: https://www.revquix.com/tools/cron-expression-explainer Cost: free, no signup --- Plain English, plus the next ten runs in your timezone and in UTC. Because the question is almost never what the fields mean - it is when the thing will actually fire. ## At a glance - Takes: A five-field Unix cron expression - Returns: Plain English, field by field, plus the next ten fire times - Handles: Both 0 and 7 for Sunday, and the step and range syntax people mistype - Privacy: Runs in your browser - nothing you paste is uploaded ## The rule that catches everybody When both the day-of-month and the day-of-week field are restricted, cron fires when either one matches - not when both do. So 0 0 1 * 1 does not mean the first of the month when it falls on a Monday. It means the first of the month, and also every Monday, which is roughly five times as often as most people intend. When one of the two fields is a star, the other simply applies and the surprise disappears. This tool spells the rule out in the explanation rather than leaving it implicit, and the next-run table makes it visible: you can see the extra fires in the dates. It is the single commonest cron bug and it usually reaches production because the expression looks correct. ## Next runs, in a real timezone Cron fields are wall-clock times in whatever zone the daemon is running in, which is why a job that should run at 02:00 IST is often scheduled for 20:30 UTC by hand and then quietly wrong after a clock change. Pick a zone here and the next ten runs are computed against that zone's actual daylight-saving rules, with the equivalent UTC instant beside each one. The calculation walks the calendar field by field rather than testing every minute, so a once-a-year expression answers as quickly as a once-a-minute one. If an expression cannot fire at all - 0 0 30 2 * asks for the thirtieth of February - it says so, which is more useful than an empty table. - Five-field Unix syntax, or six with a leading seconds field - Ranges, steps, lists, and month and weekday names - Macros: @yearly, @monthly, @weekly, @daily, @hourly - Both 0 and 7 accepted for Sunday ## What it will not do It covers standard Unix, or Vixie, cron. Quartz and Spring add L for last, W for nearest weekday, and the nth-weekday hash, and those are rejected with a message naming them rather than approximated. Ignoring a modifier we do not understand would produce a schedule that looks right and is not, which on a scheduling tool is the worst possible failure. It also cannot know your server's zone, its clock skew, or whether the daemon was running - so these are the times the expression describes, not a promise that a job fired. And @reboot is not a schedule at all: it fires once at startup, so there is nothing to list. ## Questions people ask ### Why does my job run more often than the expression looks like it should? Because you have set both the day-of-month and the day-of-week field. Cron treats that as a match on either, so the two conditions add together instead of narrowing each other. Set one of them to a star and the schedule becomes what you probably intended. ### Which cron syntax does this use - Unix or Quartz? Unix, also called Vixie cron: the five-field form used by crontab, Kubernetes CronJob and most schedulers. Six fields are accepted and read as seconds-first, which is the Quartz and Spring convention. Quartz's L, W and # extensions are refused rather than guessed at. ### Is 0 or 7 Sunday? Both, and this tool accepts either. The original Unix convention is 0 through 6 starting at Sunday; 7 was added later as an alias so that ranges like 1-7 could mean Monday through Sunday. If you are writing a range that crosses the weekend, check it against the run table rather than trusting the arithmetic. ### How are daylight-saving changes handled? Using the IANA timezone database built into your browser, which is almost certainly the same data your server uses. A wall-clock time skipped by a spring-forward resolves to the next real instant, which is what most cron implementations do; an hour that occurs twice in an autumn transition will show the first occurrence. ### Does anything I type get sent to a server? No. Parsing, explaining and the next-run calculation all happen in your browser using its own timezone data. There is no request at any point, and the page works offline once loaded.