Cronhq: A Cron Job Scheduler That Guarantees Exactly-Once Execution Using Postgres Locks

Cron jobs are a staple of virtually every backend system — yet when they fail, they often do so silently. A billing job fires twice on two separate servers, resulting in duplicate charges. A task crashes one day and nobody notices for weeks. These scenarios are painfully familiar to anyone who has done ops or backend work. Cronhq, an open-source tool, was built specifically around these pain points. Its core promise is exactly-once execution, tackling the longstanding problem of crontab's silent failures head-on.

Three Hidden Traps of Traditional Cron

The problem with native crontab isn't that it doesn't work — it's that it doesn't tell you when it stops working. Cronhq's introduction hits on several classic scenarios.

The first is duplicate execution. When you deploy the same crontab on two servers for high availability, the same job can get triggered twice. For idempotent operations like sending an email, this is a minor inconvenience. For billing, payments, or settlement tasks, it translates directly to financial loss.

The second is silent death. Once a task crashes due to an error, it can go unnoticed for weeks unless you're actively monitoring it. Native cron won't proactively tell you that a job that should have run simply didn't.

The third is the lack of retry and alerting mechanisms. When a task fails, there's no automatic retry and no timely notification — problems are typically discovered only after they've already caused damage.

Core Mechanism: Enforcing Unique Execution with Postgres Locks

Cronhq's technical foundation rests on two keywords: Rust and Postgres. Rather than taking a best-effort scheduling approach, it uses Postgres's locking mechanism to strictly guarantee that only one executor can claim a given job at any given moment.

The significance of this design is that even if you're running multiple Cronhq instances for disaster recovery, the Postgres-level lock ensures no job is triggered concurrently twice. Compared to deduplication at the application layer or relying on a distributed lock middleware, reusing database transaction locks directly is simpler and easier to deploy in a self-hosted environment — no Redis or ZooKeeper required.

Writing it in Rust delivers runtime stability and low resource consumption, a sensible trade-off for a scheduler that needs to run reliably as a long-lived background process.

The Postgres locking mechanism used here specifically refers to Advisory Locks or transaction-based row-level locking (SELECT FOR UPDATE SKIP LOCKED). The latter is the standard approach for modern database-backed task queues: multiple scheduler instances simultaneously attempt to "claim" a pending job record, and the database guarantees only one instance successfully acquires the row lock. The SKIP LOCKED clause causes other instances to skip that row rather than block. The entire "claim → execute → mark complete" flow is wrapped in a single transaction; if the executor crashes, the transaction rolls back and the job returns to a claimable state, delivering both uniqueness and fault recovery. This is what "reusing database transaction locks" really means: it depends on no additional atomic operation primitives — Postgres's own ACID guarantees are sufficient.

A Full Suite of Reliability-Focused Features

Beyond its core execution guarantee, Cronhq provides a comprehensive set of reliability-oriented capabilities:

• Retries with backoff: Failed jobs are automatically retried according to a backoff strategy, rather than being abandoned after a single failure.
• HMAC-signed Webhooks: Requests to external services are signed, ensuring the call is trusted and tamper-proof.
• Heartbeat monitors: For tasks that run outside of Cronhq — executed by external systems — heartbeat detection checks whether they "check in" on schedule, catching cases where a job should have run but didn't.
• Failure and recovery alerts: Alerts fire once when a job fails and again when it recovers, avoiding alert storms while ensuring no status change goes unnoticed.

The philosophy behind this feature set is clear: it's not enough for jobs to run — you need to know at all times whether they ran at all, and whether they succeeded.

HMAC (Hash-based Message Authentication Code) signing is a message authentication mechanism based on a shared secret key and a hash function. When Cronhq sends a request to an external Webhook endpoint, it generates a signature of the request body using a pre-agreed key and includes it in the request headers. The receiver verifies the signature with the same key, confirming the request genuinely came from Cronhq and that the content hasn't been tampered with. This is consistent with how major services like GitHub Webhooks and Stripe event notifications work. For payment callbacks or data sync endpoints triggered by scheduled jobs, this layer of verification effectively prevents malicious actors from forging scheduler requests. Heartbeat monitoring addresses a different dimension of scheduling observability: for scripts or services running independently outside the Cronhq ecosystem (such as shell scripts on other machines), they actively ping a Cronhq-provided URL after each successful execution. If no ping is received within a preset window, the job is deemed "silently absent" and an alert is triggered.

Open Source and Self-Hosted: Running the Exact Same Image

Cronhq is released under the MIT license, fully open source with self-hosting support. Developer Michael Sunmisola specifically emphasizes that self-hosted users run the exact same image as the official hosted service — a crucial point for trust, as it means there's no split between a "stripped-down open-source version" and a "full-featured commercial version."

On the business side, Cronhq offers a free tier: 5 jobs free, with paid plans for additional capacity. This is a classic open-source + SaaS dual-track approach, serving both teams who prefer to manage their own deployment and users who want an out-of-the-box solution.

On Product Hunt, the product received 78 upvotes and ranked 15th on its launch day, categorized under open source, SaaS, and developer tools.

Who Should Use Cronhq

If your business runs scheduled tasks involving payments, settlements, or notifications where duplicate or missed runs are unacceptable, Cronhq's exactly-once guarantee is its core selling point. For teams already using Postgres, the onboarding cost is especially low — no additional scheduling middleware needed.

That said, for small projects with just a handful of idempotent jobs, native crontab or a cloud platform's built-in scheduler may be perfectly sufficient. Cronhq's real value shows up as the number of tasks grows, reliability requirements increase, and production environments demand auditing and alerting. As an MIT-licensed, self-hostable solution, it offers at least one option that is both controllable and transparent.