Crontrol

• 

  The main dashboard

Inspiration

Initially inspired by OpenClaw I built an always-on AI agent harness on a mini PC in my apartment: it has a dozen cron-launched jobs in total. Everything that inspired Crontrol comes from that machine breaking quietly. Things like budget caps killing the process with an invisible failure, or a job exited 127 because cron's PATH didn't include the CLI it needed. Every incident had the same shape: I found out late, the diagnosis meant an evening of ssh and log archaeology, and the eventual fix was usually one line. That's the gap. Uptime monitors can tell you a job died. Nothing in that category reads the evidence, names the cause, and drafts the one-line fix. Built from scratch during Build Week.

What it does

Crontrol is a local-first supervisor for cron jobs, unattended AI agents, scrapers, backups, and scheduled pipelines. Its guided Codex onboarding installs the product, validates OpenAI access, and discovers existing cron and macOS LaunchAgent jobs without changing them. Once approved, wrapping a job with ct run records its exit code, duration, and secrets-redacted log tail in local SQLite. Running ct up adds a live fleet dashboard and watchdog that detects failed, late, stale, and flapping jobs. When a job fails, Crontrol sends bounded, redacted evidence to GPT-5.6. The sentinel compares the failure with the last successful run, identifies the root cause, cites the supporting evidence, and proposes a typed patch, configuration change, or command fix with risk and confidence. A second GPT-5.6 pass independently challenges the proposal before it is shown. Human approval is the default. Crontrol can apply durable patch and configuration fixes, rerun the real job, and close the incident only after verification succeeds. Users can optionally enable a tightly bounded Auto fix mode for low-risk, high-confidence fixes that pass the skeptic review; it attempts each incident once and rolls back the change if verification fails. Scheduler-command fixes cannot be applied honestly from the ledger, so Crontrol generates a ready-to-copy Codex prompt that finds the real scheduler entry, explains and backs up the change, requests approval, and validates the durable update. For remote visibility, Crontrol can publish a sanitized, view-only dashboard using GPT Sites so they are protected by ChatGPT sign-in and an owner-controlled viewer list. Logs, commands, evidence, secrets, and repair controls remain on the local machine. Same-host or privately tunneled jobs that cannot use ct run can report through the secured ping endpoint.

How we built it

Spec first: a complete build spec existed before the first Codex prompt, with the 3-minute demo as the scope contract and five milestones sequenced so the project was submittable at the end of each one. Then a single Codex thread with GPT-5.6 built it milestone by milestone: TypeScript monorepo (CLI, Fastify server, React dashboard, shared zod schemas), SQLite in WAL mode so the CLI works with no daemon running, server-sent events for live updates, and Structured Outputs for every sentinel call so diagnoses arrive as typed objects, never prose to parse. When something Codex built was broken, I described the bug back to Codex and let it fix its own code; the session log is the build history.

Challenges we ran into

1. Onboarding is important, especially if you're targeting semi-technical folks who are not used to installing a huge amount of packages in support. The way I solve that is to create a self-explanatory agent instructions inside of the repo that the agent should then be able to follow. Then the user can just tell the agent, "Here is the installation instructions" an the agent can get everything set up for them. It's a bit of a cheat, but it works quite well.
2. A seeded demo job referenced a script that didn’t exist, but GPT-5.6 proposed the job’s unchanged command as the fix. Crontrol initially treated that no-op as actionable, so every approved rerun failed identically without generating a new diagnosis. We fixed this by rejecting unchanged commands, rolling back failed fixes, feeding rerun evidence into a fresh diagnosis, and making the demo job genuinely executable.
3. The third challenge was that Crontrol could diagnose command-level fixes but could not honestly apply them because the real cron or service definition lived outside its control. We overcame this by creating a guarded Codex handoff: Crontrol generates a ready-to-copy prompt that helps Codex find the real schedule, back it up, obtain approval, and apply and validate the durable change safely.

Accomplishments that we're proud of

1) It was nice to be able to make this multiplayer and also incorporate GPT sites into this so that we could use login with OpenAI and have the whole thing work together so a teammate can check fleet health from a phone without touching the machine. 2) The full loop is real: in the final live test, ct chaos broke a job, GPT-5.6 diagnosed, cited the log lines, proposed the minimal one-line patch at 99% confidence, survived an independent skeptic pass, and one approval later the patched job reran green: 49 seconds from broken to healthy. 3) It was really fun building a CLI tool as part of this project. I'm very happy that Codex led me in that direction.

What we learned

Initially I was trying to run multiple sessions at the same time, but it's better to just have the agent review the whole project and then orchestrate its own sub-agents rather than trying to manually orchestrate. Spec-first is a force multiplier with Codex: writing the full product contract before the first prompt meant every milestone had acceptance criteria to build against, and disagreements were about the spec. The durability bug taught the deeper lesson: an AI can propose a perfect fix and the product can still lie about applying it, so honest fix semantics matter as much as diagnosis quality. And GPT-5.6 surprised us on real logs: given a redacted evidence bundle and a job description, it localized failures from context we didn't explicitly point at.

What's next for Crontrol

I'd like to make the onboarding even cleaner if I could and probably go further upstream and have the product also become about setting up cron jobs for stuff people want to do as well as monitoring and fixing them. The other thing I'm thinking of is like this scope was to be expand this to auto fix more things.

Built With

• codex