Cronhq - Cron jobs that actually run
byā¢
Cron jobs fail in silence. Two servers run the same crontab and your billing job fires twice. A job dies and nobody notices for weeks.
Cronhq is a scheduler built around one guarantee: exactly-once execution, enforced by Postgres locks ā not best-effort. Around it: retries with backoff, HMAC-signed webhooks, heartbeat monitors for jobs we don't run, and alerts that fire once on failure and once on recovery.
Rust on Postgres. MIT-licensed, self-hostable, same image we run. Free tier: 5 jobs.


Replies
Cronhq
@michael_sunmisolaĀ To your second question: before trusting it with a job that moves money, I'd look for a run ID in the webhook headers.
Exactly-once covers your side. If two workers never fire the same slot, fine. Instead retries are a different story though: if my endpoint does the work and the response gets lost or times out, you call me again and the charge happens twice on my side. In the docs I only see X-Cronhq-Timestamp and X-Cronhq-Signature, and I guess the timestamp changes on every attempt, so I have nothing to dedupe on.
I hit this with Celery and Redis: long tasks got redelivered, ran twice, and I had to build the guard myself.
Is there an execution ID that stays the same across the retries of one run? Or is it planned?
This is very useful. This has been a bugbear of mine for a long time. Well done.