Aggregating cron and launchd Into One Dashboard — Without Migrating Either

Safety: read-and-run only, on localhost

A dashboard with a run button is a foot-gun unless you bound it hard. Four invariants:

• 
  Bind 127.0.0.1 only. Never exposed off the machine.


• 
  Whitelist, no free text. The run button triggers exactly launchctl kickstart <label> or a script whose absolute path is registered in the catalog. There is no input box that accepts an arbitrary command.


• 
  Read and run only — never edit or delete. The dashboard cannot modify or remove a registration. Changes happen where they always did (your crontab, your plists). A monitor that becomes a control panel is how you corrupt your schedulers.


• 
  No secrets in the UI. Show plist EnvironmentVariables key names, never values.

The whole thing is a small FastAPI + htmx app — a few hundred lines, two dependencies. The leverage is not the framework; it is reading state that already exists instead of demanding that jobs report to you. With one distinction I did not draw sharply enough at the time: a crontab line, a plist, the process table, an artifact in someone else's directory — those are written by somebody other than the job, and they are evidence. A job's own log and its own output directory are the job talking about itself. Both are "state on disk." Only one of them can contradict the job.

The general principle

If you control the convention — here, a per-project report/ directory — and the OS already records the state you need — schedules, exit codes, log mtimes — you do not need a heavier system. You need a read-only view that joins what is already on disk. Migration and instrumentation are costs you pay forever; a glob is a cost you pay once. For a single-operator machine that keeps growing, "aggregate without migrating" scales where "move everything into one scheduler" quietly does not.

The reframe that made this tractable was giving up on the idea that jobs should report their status. They already leave traces everywhere — a crontab line, a plist, a log file's timestamp, a directory of outputs. The dashboard just has to read them.

But read them knowing who wrote them. The crontab and the process table are written by the system; the log and the output directory are written by the job. Aggregating without migrating is still the right trade — I would build this again tomorrow. Just don't mistake a trace the job left about itself for proof that the job did its work. That was the one mistake in this design, and it cost me four silent days before I saw it.

More notes at hexisteme.github.io/notes.