Cron Visual Calendar

The cron visual calendar highlights which days a standard five-field cron expression would fire in a chosen UTC month, and lists a few next run times. It complements cron calculator, which focuses on the next ISO timestamps, by drawing a month grid operators can screenshot into a runbook. Expressions are classic crontab—minute, hour, day-of-month, month, day-of-week—not systemd calendar specs and not AWS cron with a year field.

How each cell is decided

Each calendar day is tested against the month, day-of-month, and day-of-week fields. Hours that match are printed on the cell when there are few of them, for example 09h on weekdays. Minute-level detail is summarized in the next-fires list rather than drawing 1,440 ticks. Highlighted days are UTC dates. If crontab is interpreted in a local timezone, convert the civil month with care or keep the server on UTC—a common source of “it ran yesterday” tickets around DST.

Month and day lists, ranges, and steps such as */2 and 1-5/2 are supported in the same matcher used for next-fire search. Names like MON or JAN are not parsed; use numbers. Sunday is 0 or 7. Month 1 is January. Six-field cron with seconds and Quartz seven-field expressions are out of scope. Quartz day-of-week numbering also differs (Sunday = 1). Do not paste those strings here and expect a Java scheduler to match. A step on the day-of-month field such as 1-31/2 lights odd UTC dates in the viewed month; combine that with a weekday restriction only if you intend Vixie OR, not every-other-weekday.

Day-of-month OR day-of-week

When both day-of-month and day-of-week are restricted (not *), this page uses Vixie/crontab OR semantics: the job runs if either field matches. That is why 0 0 1 * 1 is not “first of the month that is also Monday” on most Linux boxes—it is the first of the month or any Monday. If you need AND logic, split into two crons or use a wrapper script.

People coming from Quartz often assume both fields must match. The grid makes the OR rule visible: extra Mondays light up even when the day-of-month is 1. Change-control tickets should attach both this month grid and the crontab line. Reviewers catch Sunday-versus-Monday mistakes faster on a grid than in a five-token string.

Expressions that light a UTC month

Paste 0 9 * * 1-5, pick a month, and calculate. Weekdays should light with 09h on those cells. 0 0 1 * * lights the first of the month. 30 4 1,15 * * lights the 1st and 15th at 04:30 UTC. 0 3 * * 0 is Sunday 03:00 UTC; in timezones west of UTC that civil Sunday evening may still be Saturday locally—write the zone on the runbook next to the grid.

An expression that never matches the selected month (for example month=2 while viewing August) highlights nothing; change month or the month field. The next-fires window still searches about two weeks ahead from “now,” which may fall in a different month. Use those ISO lines to confirm the first few UTC instants; stay on the cron calculator for a longer verbal explanation of an expression.

When 2026 has a leap day or a 31-day month, re-check expressions that use day-of-month 31 or weekday lists. The grid shows empty cells instead of assuming every month looks like the last screenshot. Recalculate for 2026 when the month contains a DST change if the daemon is not UTC.

What the grid cannot know

This is a visual aid, not a production scheduler. It does not know skipped DST hours, container downtime, or flock locks. A highlighted day means the expression matches, not that the job succeeded. Confirm against crontab -l and system logs on the machine that owns the crontab.

Day-of-week 7 is treated as Sunday, matching common Vixie behavior. Some embedded crons disagree. Test on the target image. If the job is “every N days from a start date,” a cron cannot say that; use recurring dates or a real scheduler with a start timestamp.

For Unix bounds of the same UTC day see epoch bounds. Timestamp encodings you may store when a job runs—Unix, NTP, GPS—live on the converters hub. Keep this grid next to the cron calculator so newcomers see both the month picture and the next ISO stamps.

Runbooks, DST, and expressions cron cannot say

State UTC on every screenshot. Paste the exact production string, including extra spaces you would rather not admit are in crontab -l. A visual match on this grid with a different spacing still uses the same five fields; a visual match with a Quartz seconds field does not. Reviewers should refuse six-token pastes rather than squint.

Local-zone crons around DST need a second look even when the grid is UTC. A job at 02:30 local may skip or double on the transition Sunday; this page will still light the UTC day the expression matches. Write “daemon TZ=…” on the runbook. If the business rule is every fourteen days from a kickoff timestamp, stop using cron and switch to a scheduler that stores a start instant.

Shared hosts that disable cron, lock files with flock, or skip runs while a container is down will disagree with a fully lit weekday grid. The highlight means “the expression wanted this UTC day,” not “stdout exists.” Attach logs to the ticket beside the grid for 2026 so the two artifacts are reviewed together.