Every server I've ever touched has ended up with a crontab, and every crontab eventually becomes a wall of expressions. crontab -l tells you what is scheduled — but not when things actually happen. For that, you're expanding five fields per line in your head and overlaying the results.
That works up to maybe five entries. Then one day I noticed my database backup and my log rotation had quietly piled up in the same 2 a.m. window. Nothing was broken, but it was exactly the kind of thing a picture would have shown me in one glance.
Cron syntax is both the problem and the charm here: steps like */5, ranges, lists, month/weekday names, @daily aliases — huge expressiveness packed into five tiny fields, which is precisely why the combined behavior of ten lines fits in nobody's head. I didn't want an explainer for one expression. I wanted the whole crontab laid out on a time axis. I couldn't find quite that, so I built it.
Crontab in, picture out
Cron Timeline:
Usage is what you'd expect:
- Paste your crontab (raw
crontab -loutput works — comments andPATH=lines are skipped) - Pick a view (timeline / calendar / Gantt) and a range (24 hours / 7 days / 30 days), plus a start date
- Read the picture. A collapsible entry list shows each expression with an auto-generated plain-English description
There's also an expression builder for composing new jobs — more on that below.
The design decision I care about: giving up on the scatter plot at 1,000 points
The naive timeline is a scatter chart: one execution = one SVG circle. For a 24-hour window that's fine — even a five-minute health check is only 288 dots.
Widen the range to 7 days, though, and the crontab above becomes ~2,000 dots. Mix in an every-minute job and you're past 10,000. Ten thousand SVG nodes in the DOM makes a browser very visibly unhappy.
So past 1,000 points, the chart switches automatically to a density grid: time buckets × one row per job, with cell opacity encoding how many executions land in each bucket. Buckets are hourly for the 24-hour and 7-day ranges, daily for 30 days.
I considered collapsing everything into a stacked bar chart instead, and rejected it. The entire point of a timeline is that it reads as "row = job, x = time"; stack the bars and you lose which job runs when — the one question the tool exists to answer. The rendering changes, the mental model doesn't. (If you do want aggregate totals per time slot, that exists separately as the Gantt view.)
There's a hard ceiling too: schedule computation stops at 50,000 points and shows a warning. An every-minute job over 30 days is 43,200 points, so it's a limit you can actually hit.
Smaller details
- Faithful cron semantics: restrict both day-of-month and day-of-week and cron fires when either matches — the classic OR rule that surprises everyone once. The visualization reproduces it
- @reboot has no position on a time axis, so it's skipped — but counted and reported, never silently dropped
- Expression builder: pick presets per field and you get the generated expression, a plain-English description, and the next five run times. Weekday-only schedules correctly skip the weekend
- It's part of a small static Astro site, each tool a client-side React island. No backend — your crontab never leaves the browser
When to reach for it
If your crontab has grown past the point where you can hold it in your head, paste it in before you add the next job — the empty time slots are suddenly obvious.
Feedback and feature ideas are very welcome in the comments.
Part of a small collection of free browser tools I'm building: Utilities Web
Top comments (0)