Cron Jobs had been a dead entry in the account sidebar with a Soon badge. Today it became real,
and the interesting part of building it was resisting the temptation to build something clever.
A hosting panel’s cron feature is a solved problem: the OS already has one, which runs a command on a schedule as a specific user. Rather than building a separate scheduler that runs jobs on everyone’s behalf with the panel’s privileges, each account’s jobs are installed as that account’s own scheduled tasks, so the OS runs them as that user — the same “the account’s own user does the work” boundary already used for FTP uploads and disk quota.
The whole schedule is regenerated on every write, the same pattern used for web server configs, DNS zones, and other generated files. Validation didn’t need reinventing either: the OS cron tool rejects a malformed file and leaves the previous schedule untouched.
Familiar presets (Every Minute, Every 5 Minutes, Once Per Hour, and the rest) sit alongside manual field entry, and each account gets its own Cron Email address — defaulting to its contact email — so job output has somewhere to go.
Live-verified against a disposable account on a development server: added a job through the real form, confirmed it was installed, fed the privileged action a broken schedule and watched it be rejected with previous jobs intact, then removed the account and confirmed nothing was left behind.