Launched this week

Cronhq

Launched this week

Cron jobs that actually run

78 followers

Cron jobs that actually run

78 followers

Visit website

Automation tools

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.

Free Options

Launch tags:Open Source•SaaS•Developer Tools

Launch Team / Built With

Cronhq

Maker

📌

Hi Product Hunt 👋 I'm Michael, and I built Cronhq alone over the past several months. It started with a bug I kept watching people hit at client gigs. A team scales their app from one box to two. Both boxes have the same crontab. The nightly billing job now runs twice, and a customer gets charged twice. Nobody finds out from a dashboard — they find out from an angry support ticket. The other half of it is quieter and worse: a job that just stops. No crash, no page, no alert. Six weeks later someone notices the reports have been empty since March. Cronhq is my attempt to make both of those failures structurally hard instead of merely unlikely. What's under the hood: → Exactly-once execution. Every due run is claimed through a Postgres lock row with an expiry deadline, and next_run_at moves forward BEFORE dispatch. Two workers cannot fire the same run. If a worker dies holding the lock, the expiry lets another one take over rather than the run being lost. → Retries with backoff, per job — max attempts, delay and timeout are config, not a try/except you copy-pasted from Stack Overflow. → Alerts that dedup on transitions, not state. One alert when a job starts failing, one when it recovers. Not 47 pages at 3am. → Signed webhooks. HMAC-SHA256 over timestamp.body, with per-job secrets you can rotate without downtime, so your endpoint can prove the request came from us. → Heartbeat monitors — a dead-man's switch for jobs we DON'T run. Ping a URL from your existing cron; if the ping doesn't land inside the window, you get alerted. Absence is the thing that's hard to detect. → Cron-as-code. Put your schedules in cronhq.yaml, run `npx cronhq sync`, and `npx cronhq tail` to watch executions stream live. The stack is Rust (axum + sqlx + tokio) for the scheduler, worker and API, Postgres as the only coordination primitive, no Redis, no Kafka, no scheduler-of-schedulers — and a Next.js dashboard. It's MIT licensed and self-hostable with one docker-compose. The self-hosted image is the same image the cloud runs; there are no features hidden behind a flag. Free tier is 5 jobs, paid starts at $5. Two things I'd genuinely love your take on: 1. Is "exactly-once" the right thing to lead with, or does it read as too in-the-weeds outside of backend circles? 2. What would you need to see before you'd trust this with a job that actually moves money? I'll be here all day answering everything. Thanks for reading 🙏

Report

1d ago

@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?

Report

1d ago

Cronhq

Maker

@davide_terni Yep, that’s a fair catch. Right now I don’t expose a stable execution ID across retries — the timestamp/signature headers aren’t intended to solve idempotency on the receiving side. Your example makes the gap pretty clear: the endpoint can complete successfully, the response gets lost, and CronHQ retries with no reliable key for the receiver to dedupe against. I’m going to add a stable run/execution ID that stays the same for every attempt belonging to that execution, while each attempt still gets its own metadata. Really appreciate you pointing this out, especially with the Celery example. This is exactly the kind of failure mode I want CronHQ to handle properly.

Report

21h ago

So all my code has to expose a webhook ? Love to see support for some thing like this

ssh -T user@remote-ip 'python3 /path/to/script.py'

Report

20h ago

Cronhq

Maker

@jay_janarthanan1 actually you don’t have to expose everything as a webhook 😄 CronHQ has a CLI option as well, so you can use it for scripts/commands without wrapping everything behind an HTTP endpoint. That said, direct SSH execution like your example is interesting, I’ll look into making that workflow more seamless too.

Report

19h ago

This is very useful. This has been a bugbear of mine for a long time. Well done.

Report

1d ago

Cronhq

Maker

@anton_w Appreciate it! 🙌 That exact frustration is pretty much why I built CronHQ. Glad to hear it solves a real pain point for someone else too. If you end up trying it, I’d genuinely love to hear what breaks or feels missing.

Report

21h ago

Dial

the "job runs twice" framing is exactly the failure mode that's easy to ignore until it hits a billing job specifically. Curious how the Postgres lock holds up under a worker crash mid-job - does the lock get released automatically so the next scheduled run can pick it up, or does a dead worker leave a job stuck until someone notices via the heartbeat alert?

Report

23h ago

Cronhq

Maker

@galdayan Good question. The lock is tied to the DB session/transaction, so if a worker dies and the connection drops, Postgres releases it automatically. We’re not relying on the heartbeat to clear the lock. The part I’m working through more carefully is the crash window where the target endpoint may have completed the work but CronHQ never received/recorded the success. That’s where run IDs + idempotency become important, especially for billing jobs. Definitely something I want to make explicit in the docs.

Report

21h ago

Dial

@michael_sunmisola that split makes sense, the lock question was really "does it double run" and the honest answer is that's the smaller risk, the ambiguous-completion case is the scary one because nothing looks broken. is the run ID something CronHQ generates and passes to the endpoint so the endpoint itself can dedupe on it, or is it purely internal bookkeeping on your side right now? if it's the former that would let people build idempotency into the receiving job rather than trusting CronHQ's own retry logic alone.

Report

12h ago

Cronhq

Maker

@galdayan Right now, it’s internal bookkeeping, I don’t yet pass a stable execution ID to the endpoint across retries. I’m changing that so each scheduled run gets an execution ID exposed in the webhook headers, with the same ID preserved across every retry. The receiving endpoint can then store that ID and safely dedupe the actual work, while CronHQ tracks each retry attempt separately. You’re right: without receiver-side idempotency, exactly-once dispatch alone doesn’t fully solve the ambiguous completion case.

Report

8h ago

Dial

@michael_sunmisola that's the right fix, and exposing it in the headers rather than keeping it internal is what actually lets people opt into real idempotency instead of just trusting the retry logic. one thing worth thinking through before it ships: will the header be additive (new header, old ones untouched) or will you be changing what X-Cronhq-Timestamp means, since anyone who already built a workaround off the existing headers would need a heads up either way. appreciate you thinking out loud about this in public, it's a good sign for how the product gets built.

Report

2h ago