Five fields, six fields, and what each one counts
The standard form is five fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12) and day of week (0-7 in Vixie-compatible cron, where 0 and 7 are both Sunday). A field can be a single value, a list (1,3,5), a range (9-17), a step (*/15), or a name where the dialect permits them, and this page expands all of those into words: “at minute 0, hour 9, every day of month, every month, Monday through Friday”.
Two forms add the seconds field at the front for jobs that need sub-minute timing, and Quartz turns the order around - second, minute, hour, day of month, month, day of week - counts Sunday as 1, and accepts names like MON and constants like L and W. Which form you mean changes the meaning of the same-looking numbers, which is why the dialect is a choice on the form and why the result names the dialect that read it.
Each of these forms is a choice on the page, and the dialect you pick changes how the same-looking numbers are read - which is why the result names the dialect that read the expression rather than leaving the reading ambiguous.
What it shows beyond the one-line summary
The heading is the schedule in plain words, and the rest of the page checks the reading. A field-by-field table lists each field as typed and as meant, so a range like 1-5 on day of week is spelled out as “Monday to Friday” instead of staying numbers. Counts answer the operational questions first: how many times a day the job fires, how many times a week, and how many fields were actually read.
Macros are handled too - @daily, @hourly and friends expand to the expression they stand for before the reading is shown. And when an expression does not parse, the page refuses by naming the failure: the field, the reason the value is outside the recognized range, and which dialect it was read as - because an expression that is invalid in one dialect is often perfectly legal in another.
Nothing here schedules or stores anything: the description is computed in the tab from the expression, and the download is a locally created blob, so an internal job line can be checked without ever leaving the browser.
Three things a description cannot tell you
A cron line says when to fire and says nothing about three things that decide whether the job actually runs. The first is the time zone: the expression is read in the zone the daemon runs in, so the same line on two servers fires at two different local times, and a line written for 09:00 follows that zone through daylight saving - which is why a job that ran at 08:00 or 10:00 on the changeover day behaved correctly rather than drifting.
The second is missed runs. A scheduler does not catch up: if the machine was off at the moment a job was due, that run is skipped rather than queued, and the description here is the intended schedule rather than a history of what happened. The third is overlap: nothing in the five fields stops a second copy starting while the first is still running, so an interval shorter than the job is a recipe for two copies of it.
None of this is visible in the expression, which is the argument for reading it out before it ships. The description gives you the cadence; these three questions tell you whether the system can survive that cadence. "Every fifteen minutes" and "a job that finishes in four" are two different claims, and only one of them is in the line.
Danfio