Read a cron expression in plain words

Cron is readable, right up until it isn’t

0 4 * * MON you can probably do in your head. */7 3-5 * * * you probably can’t, and the reason is not that it is complicated — it is that the syntax gives you no landmarks. Five whitespace-separated fields in an order you half-remember, where a star means “every”, a slash means a step, and the fifth field counts days from Sunday except when your scheduler counts them from Monday.

Then there is the rule that catches everyone exactly once. When both the day-of-month and the day-of-week field are set to something other than a star, cron does not intersect them — it ORs them. So 0 9 1-31 * 1-5 looks like “weekday mornings” and fires on Saturday too. A crontab you have to squint at is a crontab that eventually fires at a time nobody intended, usually in production, usually at 3am.

The usual fix is a cron-explainer website. It works, and it is one more tab, one more paste, and one more page you have to trust with the shape of your infrastructure.

The sentence, the fields, and the proof

The description leads, because “At 4:00 AM on Monday” is the thing you copied the expression to obtain. Under it, every field is shown as you wrote it beside what it admits, so an expression you mistyped is visibly wrong rather than quietly different.

Then the next five run times, computed rather than described — which is what turns the sentence from a claim into something you can check. The day-of-month/day-of-week OR rule is applied to both the sentence and the fire list, so the two never disagree with each other or with your scheduler.

The two ways this pane refuses to be confidently wrong

Fire times are shown in your local time, and the caption says so, every time, naming your zone. A crontab runs in its server’s zone; a developer who reads 4:00 AM here, assumes it is the server’s, and ships accordingly has been misled by the tool rather than merely under-informed. That one line is what earns the section the right to print absolute times at all.

And when a schedule fires rarely — or never — that is reported as a finding instead of an empty box. 0 0 29 2 * fires once in four years and says so. 0 0 30 2 * is February 30th and fires never, which is a real bug in somebody’s crontab and the single most useful thing the panel could tell you. When a shape genuinely has no good sentence, you get a shorter honest one rather than a longer wrong one.

It is already there when you look

There is nothing to launch and no button to press. Copy the line from your crontab, your Kubernetes manifest or your CI config, press ⌘⇧V, read it, press esc. Cron is one of fifteen kinds Rakkun tells apart on sight, alongside JSON, JWTs, SQL, certificates, stack traces and the rest of what you copy in a day.

And it stays on your machine: Rakkun ships with no network entitlement, so macOS itself prevents the app from opening a connection. Your infrastructure’s schedule is not an interesting secret until it is in somebody else’s server log.