Cronhq

Cronhq is a distributed cron scheduler that fires webhooks on a schedule. You point Cronhq at a webhook URL, and it calls it at the times you define, retries it when it fails, and pages you when something breaks — and again the moment it recovers. It is designed for developers and engineering teams who need scheduled tasks to run exactly once, even when more than one server or worker is running the same schedule. Rather than maintaining crontab entries by hand across machines, you create a job through the API or the dashboard, and Cronhq takes care of execution, retries, logging, and alerting. The product's own promise is simple and direct: cron jobs that actually run. The problem Cronhq addresses is that cron jobs fail in silence. If two servers run the same crontab, the same billing job can fire twice, which means duplicate charges or duplicate records. If a job dies, nobody notices for weeks, because a missing run produces no error message, no alert, and no trace — there is simply nothing to see. Standard crontabs provide no coordination between workers that could prevent double execution, no retry logic, no durable execution history, and no alerting when a run stops happening. Teams are left to write their own locking, their own backoff, and their own monitoring, or to accept that some scheduled work will quietly stop running. Cronhq is built around one guarantee — exactly-once execution, enforced by Postgres locks rather than best-effort behavior — and then wraps the surrounding operational needs, such as retries, signed webhook delivery, heartbeat monitoring, and deduplicated alerts, into the same system. Cronhq's first capability area covers the integrity and observability of the calls it makes. Every request Cronhq sends carries an X-Cronhq-Signature header, computed as an HMAC-SHA256 over timestamp.body, along with an X-Cronhq-Timestamp header. Each job gets its own secret, and you can rotate that secret at any time with no downtime, so a leaked key does not force you to tear down and recreate the job. On the receiving end, this lets you verify that a scheduled call genuinely came from Cronhq before acting on it, which matters for anything that touches money, data, or infrastructure. Running alongside that is the heartbeat monitor: you ping a URL on every run, and if the expected window — the period plus a grace interval — is missed, Cronhq flips the monitor to DOWN and pages you once. Cronhq describes this as cron's inverse: proof of absence rather than proof of presence. The second capability group is about managing schedules as part of your codebase rather than as clicks in a UI. The Cronhq CLI installs with npm i -g cronhq, or runs directly with npx cronhq --help. Running npx cronhq sync reconciles a cronhq.yaml file in your repository — it creates, updates, and prunes jobs so your schedules live in version control and move through review like any other change. Running npx cronhq tail live-streams executions straight to your terminal, so you can watch a job's output without leaving your editor or shell. Inside the dashboard, a ⌘K command palette lets you type schedules in plain English: writing "every weekday at 9am" returns the valid cron expression 0 9 * * 1-5, with a plain-English preview so you can confirm the schedule is right before saving it. The third group covers what happens after a run fails. Retries are built in with backoff, configured as a max retry count and delay per job, so a transient failure gets a few more attempts at increasing intervals instead of being written off immediately. The terminal status and the last error always land in the job's history, which means the postmortem writes itself. Every execution is logged with its status, duration, HTTP code, and response body, newest first, searchable, and retained — the job's history belongs to you and stays available. Alerts are deduplicated to avoid noise: a failure alert fires on the third bad run in an hour, not on the first, and the recovery alert fires on the first success after a streak. That is a deliberate design choice illustrated in Cronhq's own diagrams, where repeated failures after an alert stay silent, and a recovery message such as "nightly-rollup recovered after 3 failures. Last 6 runs: all 2xx." closes the loop. Alerts can be wired to email or Slack. The mechanism behind Cronhq's central guarantee is a Postgres lock. Two workers can never fire the same scheduled execution: each run is claimed through a database lock before it proceeds, so a duplicate worker simply loses the race and does nothing. If a worker crashes mid-job, the lock expires and another worker picks the execution up. This is what makes the exactly-once claim structural rather than aspirational — the coordination lives in the database that both workers already trust, not in a best-effort in-memory flag. Around that core, Cronhq schedules, delivers, retries, records, and alerts, and the whole system is built in Rust on Postgres. It is MIT-licensed and self-hostable, running the same image Cronhq runs in production. For teams that rely on scheduled work, the outcome is that jobs stop disappearing without anyone noticing. Duplicate executions from racing workers are eliminated by the lock-based claim, so a nightly billing job fires once instead of twice. Transient failures are absorbed by retries with backoff, while permanent failures surface in a searchable execution history complete with HTTP codes and response bodies. Alerting is deliberately quiet: one page on the third failure in an hour and one on recovery, so the signal is that something is actually wrong rather than that a single run flaked. Heartbeat monitors extend the same coverage to jobs Cronhq does not run itself, turning a silent absence into a page. And because schedules can live in a cronhq.yaml file and reconcile through the CLI, they become reviewable artifacts in the repository rather than configuration that only exists in a dashboard. Scheduled webhooks are the core workflow: a nightly rollup job, a nightly digest, a metrics refresh, a queue drain, a cache warm, a cleanup job, or a health poll, each configured with a name, a cron schedule, a webhook URL, and a timezone such as America/New_York. Jobs that run elsewhere — on your own infrastructure or another provider — can still be covered by pointing a heartbeat monitor at an endpoint you ping on every run, so if the ping window is missed, you are paged. Teams that want their schedules under version control use npx cronhq sync against a cronhq.yaml file, and teams that prefer watching from a terminal use npx cronhq tail to live-stream executions. Anyone who needs to sanity-check a schedule quickly can type the schedule in English into the ⌘K command palette and get the cron expression back with a plain-English preview. Cronhq is aimed at developers, engineering teams, and anyone running scheduled work in a distributed system, and it is listed among Developer Tools, Open Source, SaaS, and GitHub topics. Delivery is by webhook, so it integrates with any HTTP endpoint, including your own API; alerts go to email or Slack. The stack is Rust on Postgres. Cronhq is MIT-licensed and self-hostable using the same image the hosted service runs, and it offers a free tier covering 5 jobs. Getting started takes four steps on one screen: sign up with an email to receive a one-time link that mints a 36-character API key starting with chq_, create a job with a schedule and URL, watch executions arrive in the log, and wire up email or Slack alerts. In short, Cronhq exists to make one promise true: cron jobs that actually run. It enforces exactly-once execution with Postgres locks, retries failures with backoff, signs every webhook with HMAC-SHA256, monitors jobs it does not run via heartbeat pings, and alerts once on failure and once on recovery. Built in Rust on Postgres, MIT-licensed and self-hostable, with a free tier of 5 jobs, it gives teams a scheduler that treats reliability as the starting point rather than an afterthought.