Crontab Guru

In-Depth Guide

Cron is the POSIX.1-2017 scheduled-task primitive, and its five-field syntax — minute, hour, day-of-month, month, day-of-week — is the single most misread DSL in systems programming. A cron expression like /15 9-17 1-5 says 'every 15 minutes, between 9 AM and 5 PM, Monday-Friday', but the combination rules between day-of-month and day-of-week, the off-by-one in 0 0 0 versus 0 0 * 7, and the DST interaction on systems where cron runs in local time versus UTC all conspire to produce surprising behaviour. FastTool's crontab explainer parses the expression, shows the plain English meaning, predicts the next five runs in your chosen timezone, and highlights subtle edge cases. It also recognises the special strings @reboot, @yearly, @monthly, @weekly, @daily, and @hourly defined in Vixie cron, the de facto implementation shipped with most Linux distributions since the mid-1990s.

Why This Matters

Cron bugs are quiet. A job that was supposed to run every 15 minutes but actually runs every hour because 15 was written instead of /15 silently under-runs for weeks before anyone notices. A backup job scheduled at 2 * fires at the 2nd minute of every hour rather than 2 AM nightly, saturating the backup volume. A DST transition skips or duplicates a run on a local-time cron. These are textbook incidents you can entirely prevent by reading the expression in natural language before saving the crontab — which is exactly what this tool provides.

Real-World Case Studies

• Backup schedule audit. An SRE is investigating why the nightly backup has not run for two weeks. Pasting the expression 2 into the explainer reveals 'At minute 2 of every hour' — the intended 0 2 * ('At 02:00 every day') has the two fields swapped. The fix is a one-line crontab edit, and the explainer's next-five-runs preview confirms the new expression fires at 02:00 tomorrow rather than at 02:02 tonight, avoiding the embarrassing rollback of a recovery exercise that never had data to recover.
• DST migration planning. A finance team runs a daily reconciliation job at 0 3 local time. The explainer, with timezone set to America/New_York, reveals that on 13 March 2026 (DST start) the 03:00 slot does not exist — the clock jumps from 02:00 to 04:00. The team switches to UTC cron (0 7 which equals 03:00 EST and 03:00 EDT — wait, that also drifts), ultimately settling on two jobs around the DST boundary to guarantee exactly-once execution regardless of the clock discontinuity.
• Weekend-only maintenance. An SRE writes 0 3 0,6 intending 'at 03:00 on Saturday and Sunday'. The explainer confirms 'At 03:00 on Sunday and Saturday' — the 0 and 7 both mean Sunday in Vixie cron, so 0 is fine; 6 is Saturday. But if she had written 0 3 6,0, the explainer would have clarified that the ordering does not matter and the meaning is identical. A quick check catches the ambiguity before a night of debugging runs that fire on every day but Sunday.

Technical Deep Dive

Cron expressions follow the POSIX.1-2017 five-field syntax: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), day-of-week (0-6, where both 0 and 7 represent Sunday per Vixie cron extensions). Each field accepts single values (5), lists (1,15,30), ranges (1-5), steps (/15 meaning every 15, or 0-30/5 meaning every 5 within 0-30), and the wildcard . Month and day-of-week names (JAN-DEC, SUN-SAT) work as aliases. A critical rule from POSIX: when both day-of-month and day-of-week are restricted (neither is ), the job fires when either matches — an OR semantic that surprises everyone on first encounter. Special strings map to equivalent expressions: @reboot fires on daemon startup, @yearly / @annually is 0 0 1 1 , @monthly is 0 0 1 , @weekly is 0 0 0, @daily / @midnight is 0 0 , @hourly is 0 *. DST handling is implementation-defined: Vixie cron runs missed jobs skipped forward and runs duplicated jobs only once (per the 'spring forward / fall back' rules documented in cron.c source). Systemd timers avoid this entirely by using monotonic time.