cronviz

One command to know what's scheduled to run on this server, when, and whether it actually ran last time.

cronviz is a stdlib-only Python tool that scans every scheduling source on a Linux box (/etc/crontab, /etc/cron.d/, /etc/cron.{hourly,daily,weekly,monthly}/, per-user crontabs in /var/spool/cron/, and systemctl list-timers) and produces a unified, time-ordered view of every scheduled job: name, schedule, source file, next run, last run (when known).

It's the answer to the question every SRE/devops engineer asks at 3 AM: "what is actually scheduled to run on this box?"

Why

A typical Linux server in 2026 runs scheduled work from at least four sources:

• /etc/crontab — root-managed system jobs
• /etc/cron.d/* — package-installed cron snippets
• /etc/cron.{hourly,daily,weekly,monthly}/ — interval directories
• /var/spool/cron/<user> — per-user crontabs (and crontab -l shows nothing if you're not the right user)
• systemctl list-timers — systemd timer units (now the modern default for many packages)

Anyone who has SSH'd into a server and tried to figure out why a script ran at 3:14 AM knows the pain. There is no single command that lists all of this. crontab -l shows your own crontab. systemctl list-timers shows systemd. find /etc/cron* shows cron snippets but not their actual schedule. None of them join across sources or sort by next run time.

cronviz fixes that.

Status

v0.2 (2026-04-08). Local CLI. Reads all sources, produces unified output, and optionally annotates each job with its last-run timestamp via --history. Stdlib only, no external dependencies.

Roadmap:

Version	What it adds	Status
v0.1	CLI scan, table/JSON/TSV/Markdown output, stdlib only	✅ shipped
v0.2	Last-run history (--history) via systemctl show + journalctl SYSLOG_IDENTIFIER=CRON	✅ shipped
v0.3	Web dashboard (Flask, single-server)	planned
v0.4	Multi-server agent + hosted SaaS tier (paid)	planned

Install (planned)

pip install cronviz
cronviz                       # default table view
cronviz --json                # machine-readable
cronviz --md > report.md      # markdown report for incidents
cronviz --history             # annotate each job with its last-run timestamp
cronviz --history --user www-data --md  # markdown report of www-data jobs with history

Real output example (this server, v0.2 with --history)

NAME                          SCHEDULE         USER  SOURCE                 NEXT_RUN              LAST_RUN              COMMAND
sysstat-collect.timer         systemd-timer    root  systemctl list-timers  2026-04-09 00:00 UTC  2026-04-08 22:50 UTC  sysstat-collect.service
man-db.timer                  systemd-timer    root  systemctl list-timers  2026-04-09 04:58 UTC  2026-04-08 03:48 UTC  man-db.service
fstrim.timer                  systemd-timer    root  systemctl list-timers  2026-04-13 00:27 UTC  2026-04-06 00:40 UTC  fstrim.service
command (sysstat cron)        5-55/10 * * * *  root  sysstat                                      2026-04-08 22:45 UTC  command -v debian-sa1 ...

Why "boring stack"

Same philosophy as the rest of my projects:

• Stdlib only for the CLI. No requests, no click, no rich. The tool runs on a fresh Python 3.9+ install with zero deps.
• Single file if possible, three files maximum. Easy to audit, easy to vendor.
• No daemon, no service for v0.1. You run it, it prints, it exits.
• SQLite + Flask + systemd for the future hosted version. Same pattern that runs Funding Finder on a $5 VPS.

License

MIT (planned). Open source. The hosted version is the paid product, the CLI is the vitrine.