Cronhub

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me job monitoring and triggering that replaces Cronhub: something outside my infrastructure that notices a job did not run, and can start one that has no cron of its own.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A scheduler process separate from the web process
- Caddy in front, **on a machine that is not the one running your jobs**

THE DATA MODEL
- monitors: id, key, name, kind, schedule, timezone, grace_seconds, max_duration_ms, is_active, muted_until — kind is watch or trigger
- triggers: monitor_id, method, url, headers_json, body, timeout_ms, retry_json — for the ones this service starts
- pings, runs, states, incidents, alerts — the same shape as any absence monitor
- Every ping and every trigger attempt kept. When a job did not run, the record of what this service tried is the first thing you need

WATCHING
- A ping URL per monitor, with start, success and failure endpoints and a run id pairing a start with its finish
- Answer in milliseconds and record after responding. The ping must never slow a job or fail one — document a curl with a timeout and a fallback of true
- Compute the next expected instant from the schedule, add the grace period, and alert when it passes with no ping
- Both daylight-saving transitions decided, documented and tested
- The scheduler is small, separate, and has a dead-man's switch of its own pinging an external service, because a crashed watcher looks exactly like a quiet night

TRIGGERING, WHICH IS THE HALF THAT NEEDS CARE
- An HTTP request on a schedule, with a timeout, a retry policy and a recorded result
- **The endpoint being called must be idempotent, and the service must not assume it is.** A retry after a timeout may run the job twice, so send an idempotency key and say clearly in the README that the receiving side has to honour it
- Never retry a job whose result is unknown more than once without a deliberate setting. Doubling a nightly billing run is worse than skipping it
- Overlap protection: if the previous run has not reported finishing, skip or queue rather than starting a second, chosen per monitor
- The trigger signs its request so the receiving endpoint can verify it, and the secret is per monitor

BEYOND FAILING
- Alert when a job exceeds its maximum duration while it is still running
- Alert on a duration trend above the rolling 95th percentile, which is how a backup that has grown from four minutes to fifty is caught before it fails
- Flapping suppressed into one incident

ALERTS
- Email, webhook, chat and a shell command, with escalation after N minutes unacknowledged and acknowledgement from a link that needs no login
- Recovery always, in the same channel; muting always with an end time

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SMTP_URL, SESSION_SECRET, HASH_SALT, DEADMAN_URL
- Migrations on boot, each once; nightly backup off the machine
- Health endpoint reporting the scheduler's last tick and the oldest overdue monitor

WHAT MATTERS MOST
The separate scheduler and the idempotency key. Deploy it somewhere unrelated to what it watches, then pull the plug on a job mid-run and confirm you are told — and that nothing was started twice.