Cronhq

Cronhq is a managed scheduler for cron jobs. You point it at a webhook URL, and Cronhq fires that webhook on your schedule, retries it when it fails, logs every execution, and pages you when something breaks — then pages you again the moment it recovers. It is built for developers and engineering teams who rely on recurring jobs to keep their systems running: nightly rollups, invoice generation, metrics refreshes, cache warming and digest emails. The product's headline promise is exactly-once execution, enforced by Postgres locks rather than best-effort coordination, so the same scheduled run can never be fired twice by two different workers. Cron jobs fail in silence. Two servers running the same crontab can race each other and a billing job fires twice — charging a customer twice or sending a duplicate invoice. A job dies and nobody notices for weeks, because the absence of an error message is not the same thing as success. Traditional crontab offers no retries, no alerting, no execution history and no protection against duplicate runs across multiple workers. Cronhq was built around that specific failure mode: a scheduler whose one guarantee is that each scheduled execution happens exactly once, with retries, alerts and logs wrapped around it so that failures become noisy instead of silent. Security of the callback is handled with signed webhooks. Every request Cronhq makes carries an X-Cronhq-Signature header — an HMAC-SHA256 signature computed over timestamp.body — plus an X-Cronhq-Timestamp header. Each job gets its own secret, and that secret can be rotated at any time with no downtime. Receivers can therefore verify that a scheduled call really came from Cronhq and was not spoofed or replayed by a third party. For teams that expose an internal endpoint so that a scheduler can reach it, signed webhooks are the difference between an open endpoint and an authenticated one, and verification is a short, documented snippet of code. Cronhq also covers the jobs it does not run. A heartbeat (dead-man's switch) monitor is a URL you ping on every run of a job that lives somewhere else. If the ping misses its window — the expected period plus a grace period — Cronhq flips the monitor to DOWN and pages you exactly once. The site describes this as cron's inverse: proof of absence rather than proof of presence. It is the right tool for jobs running inside your own infrastructure or on a machine that you can only observe, not schedule, so silent failure still turns into a notification. Schedules themselves are managed as code. Cronhq ships a CLI, installed with npm i -g cronhq or run directly with npx cronhq --help. npx cronhq sync reconciles a cronhq.yaml file in your repository, creating, updating and pruning jobs so your schedules live in version control alongside the code they trigger. npx cronhq tail nightly-rollup live-streams executions straight to your terminal, which makes it easy to watch a job's first runs from the same place you watch logs. Cron-as-code means schedule changes go through code review instead of a dashboard click that nobody remembers making. Inside the dashboard, ⌘K opens a command palette that accepts plain English. Type "every weekday at 9am" and Cronhq returns a valid cron expression — 0 9 * * 1-5 — with a plain-English preview so you can confirm the schedule before saving and never guess wrong. Setting up a job is deliberately small: sign up with your email, receive a one-time link, and a 36-character API key starting with chq_ is minted for you. Then you POST a name, a schedule, the webhook URL and a timezone to /v1/jobs. Every execution is logged with status, duration, HTTP code and response body, newest first, searchable and yours forever. The scheduling model is built in Rust on Postgres, and the exactly-once guarantee comes from a Postgres lock claiming each run: two workers can never fire the same scheduled execution, and if a worker crashes mid-job another picks up after the lock expires. Retries are configured per job with a maximum retry count and delay; backoff means a failing webhook is retried after increasing waits rather than hammering the endpoint, and the terminal status plus the last error land in your history so the postmortem writes itself. Alerts are deduplicated: a failure alert fires on the third bad run in an hour rather than the first, and the recovery alert fires on the first success after a streak. Runs continue silently and successfully in between, so an outage produces one page and one all-clear rather than a notification storm. The result for users is a recurring workload that stops being a source of quiet anxiety. Jobs that used to fail invisibly now produce an explicit status, a duration, an HTTP code and a stored response body for every run, and the dashboard surfaces throughput, P95 latency and success rate alongside a live execution feed. Because duplicates are prevented at the database level, billing-style jobs can be trusted not to double-fire when more than one worker is running. Because retries and alerts are built in rather than bolted on, the team hears about a problem once, when it matters, and hears again only when it is fixed. The concrete workflows described on the site follow the same shape: choose a schedule, point Cronhq at a URL, and let it handle firing, retrying and alerting. A nightly-rollup job posts to api.you.com/cron/rollup at 2am; a metrics refresh calls metrics.app/refresh; a billing run posts to billing.io/invoices and, if it returns a 504, is retried rather than lost; cleanup, sync, digest and cache-warming calls run on their own intervals. Heartbeat monitors cover the jobs Cronhq does not host, flipping DOWN when an expected ping is missed. And for teams who want their schedules reviewed like code, cronhq.yaml plus npx cronhq sync keeps the whole set of jobs reproducible from a repository. Cronhq is aimed at developers and engineering teams who depend on scheduled work — webhooks, rollups, invoices, digests, health-style pings and cache maintenance — and who need those runs to be reliable rather than best-effort. It runs on Rust and Postgres, and the same image the team operates is MIT-licensed and self-hostable, so teams can run the scheduler themselves or use the managed service. There is a free tier covering 5 jobs, which makes it possible to try the exactly-once guarantee, the signed webhooks and the alerting on real schedules before committing further. In short, Cronhq takes the oldest, least trustworthy primitive in a stack — the cron job — and rebuilds it around a single hard guarantee: each scheduled execution runs exactly once, is retried when it fails, and is reported when it breaks and when it recovers. That is what "cron jobs that actually run" means in practice.