Cronhq

The Silent Killer in Your Ops Stack Is Not Your Ads, It’s Your Scheduled Jobs

Every cross-border operator I know spends their mental energy on the visible levers: ad spend on Shopify and Amazon, creative angles, supplier negotiation, TikTok Shop live calendars. Almost nobody spends a minute on the invisible layer that actually moves money inside their business — the scheduled jobs that push orders to 3PLs, sync inventory between Amazon Seller Central and a DTC storefront, fire abandoned-cart emails through Klaviyo, reconcile payouts, and kick off nightly billing. When those jobs run twice, you double-charge a customer or double-ship an order. When they silently stop, you find out six weeks later from an angry email. So when I saw Cronhq launch on Product Hunt — built solo by Michael Sunmisola — my ears perked up, because the failure modes he describes are exactly the ones that eat margin at scale.

What Cronhq Actually Solves (and Why It’s Not Just a Backend Toy)

The pitch is deceptively simple: a scheduler that makes “runs twice” and “silently stops” structurally hard instead of merely unlikely. That framing matters because most cross-border sellers have never thought about their job runner as a piece of infrastructure. They think about their job runner as “that cron tab on the droplet” or “the Heroku scheduler” or “whatever Zapier was doing before we outgrew it.”

The specific mechanics Sunmisola describes are worth walking through because they map onto real operational pain:

• Exactly-once execution via a Postgres lock row with an expiry deadline, where next_run_at moves forward before dispatch. Two workers cannot fire the same run.
• Retries with backoff configured per job — max attempts, delay, and timeout as config rather than copy-pasted try/except blocks.
• 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 using HMAC-SHA256 over timestamp.body, with per-job secrets that rotate without downtime.
• Heartbeat monitors — a dead-man’s switch for jobs Cronhq doesn’t run. You ping a URL from your existing cron; if the ping doesn’t land inside the window, you get alerted.
• Cron-as-code via a cronhq.yaml file, npx cronhq sync, and npx cronhq tail to stream executions live.

The stack is Rust (axum + sqlx + tokio) with Postgres as the only coordination primitive — no Redis, no Kafka, no scheduler-of-schedulers — plus a Next.js dashboard. It’s MIT licensed and self-hostable with one docker-compose file, and the self-hosted image is the same image the cloud runs. Free tier is 5 jobs; paid starts at $5.

If you’ve ever scaled a store from one server to two and watched your nightly inventory sync fire twice, you already understand why this is interesting. If you haven’t, you will.

Why Amazon sellers should care more than Shopify ones

Shopify sellers tend to live inside the Shopify admin. Order flows, fulfillment notifications, and most automation are handled by the platform or by apps that plug into it. The blast radius of a bad cron job is usually a delayed email.

Amazon sellers are different. Their operations are almost always a patchwork: Seller Central for listings and orders, a separate ERP or inventory tool, a 3PL integration, a repricer, a review-request tool, a PPC automation layer, and a custom script someone wrote in 2022 that syncs FBA inventory to a Google Sheet. That custom script is a cron job. If it runs twice, you might push a phantom restock order to your supplier. If it stops, you might miss a replenishment window and go out of stock on your best ASIN during Q4.

The heartbeat monitor feature is the one Amazon operators should pay closest attention to. It’s specifically designed for the case where a job doesn’t run at all — no crash, no alert, no page. That’s the failure mode that kills Amazon businesses quietly, because Seller Central won’t tell you your own sync script died. You find out when your inventory goes negative.

Where the math breaks

The $5 starting price is almost a rounding error for any seller doing meaningful volume. But the real question isn’t price — it’s whether the tool replaces or adds to your existing stack. If you’re already running Celery with Redis, or Sidekiq with Redis, or a managed service like Render cron jobs or Railway, you’re not going to rip that out for a $5 tool. You’ll only switch if the specific failure modes Cronhq addresses — exactly-once, transition-based alerting, heartbeat monitors — are ones you’ve actually been burned by.

And you probably have been burned by them. You just haven’t attributed the burn to the scheduler.

How It Stacks Up Against What Cross-Border Sellers Already Use

Let’s be honest about the competitive set, because “cron scheduler” is a crowded category and most sellers have already picked a default.

Zapier and Make are the entry-level answer. They’re fine for “when an order comes in, add a row to a sheet.” They are not fine for anything that moves money, because they don’t give you exactly-once semantics, they don’t give you signed webhooks with rotating secrets, and their retry behavior is opaque. If you’re running billing or refund logic through Zapier, you’re one bad retry away from a support ticket.

AWS EventBridge Scheduler and Google Cloud Scheduler are the “grown-up” answer. They’re reliable, but they’re also cloud-native, which means your job logic has to live inside that cloud’s ecosystem to get the full benefit. For a cross-border seller already juggling AWS for one thing, GCP for another, and a VPS for a third, adding another cloud-specific scheduler is friction, not relief.

Celery, Sidekiq, and BullMQ are the developer answer. They’re powerful and flexible, and if you have an engineer on staff, they’re probably what you’re using. But they don’t solve the “dead-man’s switch for jobs we don’t run” problem out of the box, and they don’t give you a dashboard a non-engineer can read at 3am. Most cross-border sellers don’t have an engineer on staff. They have a VA who knows how to restart a droplet.

Managed cron services like Cronitor and Healthchecks.io solve the monitoring half of the problem beautifully — heartbeat pings, alerting, dashboards. But they don’t run your jobs. You still need something to actually execute the work, and you still need to solve exactly-once yourself.

Cronhq’s bet is that there’s a middle ground: a tool that runs the jobs and monitors them and gives you the exactly-once and idempotency primitives without forcing you into a specific cloud or a specific language runtime. That’s a real gap. Whether it’s a big enough gap to build a business on is a different question.

The idempotency gap the maker didn’t lead with

Here’s where the Product Hunt thread gets genuinely interesting, and where I think the real product story lives.

A commenter named Davide Terni raised the sharpest objection in the thread: exactly-once execution covers Cronhq’s side, but it doesn’t cover the receiving endpoint’s side. If your billing endpoint does the work, the response gets lost or times out, and Cronhq retries — the charge happens twice on your side. He specifically noted that the docs only show X-Cronhq-Timestamp and X-Cronhq-Signature headers, and since the timestamp changes on every attempt, there’s nothing stable to dedupe on.

Sunmisola’s response was refreshingly honest: “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.” He committed to adding a stable run/execution ID that stays the same across every attempt of one execution, while each attempt still gets its own metadata.

This is the single most important feature for anyone using Cronhq to move money. Without it, “exactly-once” is a half-truth — it’s exactly-once dispatch, not exactly-once effect. The dispatch is the easy part. The effect is where the double charges live.

A second commenter, Gal Dayan, pushed on the same theme from a different angle: what happens if a worker crashes mid-job? Sunmisola explained that the lock is tied to the DB session/transaction, so if the worker dies and the connection drops, Postgres releases it automatically — the heartbeat isn’t what clears the lock. But he also flagged the “ambiguous completion” window as the scary one: the target endpoint may have completed the work, but Cronhq never received or recorded the success. That’s the case where nothing looks broken and yet you’ve double-charged.

For a cross-border seller, this is the whole ballgame. Your supplier payment job, your refund batch, your subscription renewal — all of these are exactly the jobs where ambiguous completion is unacceptable. The fact that the maker is publicly acknowledging the gap and committing to close it is a good sign. The fact that it isn’t closed yet is a reason to wait, or to build the idempotency guard on your own side.

Why the CLI answer matters more than it sounds

A third commenter, Jay Janarthanan, asked whether everything has to be exposed as a webhook — he wanted to just SSH into a box and run a Python script. Sunmisola clarified that Cronhq has a CLI option so you can run scripts and commands without wrapping everything behind an HTTP endpoint, and that direct SSH execution is something he’d look into making more seamless.

This matters more than it sounds for cross-border operators, because a huge fraction of the “automation” in this industry is shell scripts. Pull a CSV from a supplier portal. Rename it. Push it to an FTP. Run a Python script that hits an internal API. None of that wants to be a webhook. If Cronhq only spoke HTTP, it would be useless to half the sellers who need it. The CLI path keeps it relevant.

What Cross-Border Sellers Should Actually Borrow From This

Even if you never sign up for Cronhq, there are four operational patterns in this launch worth stealing for your own stack.

First, adopt transition-based alerting. If your current setup pages you every time a job fails, and your job fails intermittently, you’ve trained yourself to ignore the pages. That’s worse than no alerting. Alert on the transition from healthy to failing, and again on the transition back. One page, not forty-seven.

Second, add heartbeat monitors to every job you don’t control. Your supplier’s API, your 3PL’s webhook, your payment processor’s reconciliation feed — you can’t put a cron in front of those, but you can ping a URL from your own job that watches them. If the ping doesn’t land, something upstream is broken. This is the single highest-ROI monitoring pattern in e-commerce ops and almost nobody does it.

Third, treat idempotency keys as mandatory for anything that moves money. Every job that charges, refunds, pays a supplier, or adjusts inventory should carry a stable key that the receiving side can dedupe on. If your current scheduler doesn’t give you one, generate it yourself and pass it in the payload. Don’t wait for your vendor to ship the feature.

Fourth, put your schedules in code. If your cron jobs live in a web UI somewhere and nobody remembers what they do, you have a bus-factor problem. A cronhq.yaml (or any equivalent) checked into git is a small thing that pays off enormously the first time you need to onboard someone or audit what’s actually running.

Where I think Cronhq falls short

I’ll be direct: the launch leads with “exactly-once,” and Sunmisola himself asked the thread whether that’s the right thing to lead with or whether it reads as too in-the-weeds outside backend circles. My answer is that it’s the wrong lead for this audience. Cross-border sellers don’t wake up thinking about exactly-once semantics. They wake up thinking about double charges and missed syncs. The lead should be the customer story, not the CS concept.

The second gap is the one the thread surfaced: no stable execution ID across retries at launch. For a tool whose entire pitch is “trust this with your billing job,” that’s a missing primitive, not a nice-to-have. Sunmisola has committed to shipping it, which is the right call, but until it’s live, anyone using Cronhq for money-moving jobs needs to build their own guard.

The third gap is ecosystem. There’s no native Shopify, Amazon, or Klaviyo integration mentioned. That’s fine for a developer-first tool, but it means a cross-border seller has to bring their own glue. For a solo-built product at this stage, that’s expected. For a seller evaluating it against a managed service that ships with pre-built connectors, it’s a real trade-off.

What I’d Watch / Test Next

If you’re a cross-border operator reading this and wondering whether to spend an afternoon on it, here’s what I’d actually do this week.

First, audit your current scheduled jobs. List every recurring task in your business that touches money, inventory, or customer communication. For each one, write down: what happens if it runs twice? What happens if it silently stops? If you can’t answer both questions confidently, that job is a liability.

Second, install a heartbeat monitor on your three most critical jobs — even if you don’t use Cronhq. Healthchecks.io has a free tier that takes ten minutes to set up. The point isn’t the tool; the point is that you stop being blind to silent failures.

Third, if you’re already running custom cron jobs on a VPS or a small cloud instance, spin up the Cronhq self-hosted docker-compose on a staging box and migrate one non-critical job to it. Watch how the alerting behaves. Watch how the CLI feels. Don’t move anything that touches money until the stable execution ID ships.

Fourth, bookmark the Product Hunt thread and check back in a month. The maker is engaged, the feedback is sharp, and the roadmap items that came out of the comments — stable run IDs, SSH execution — are exactly the ones that determine whether this becomes a real tool for operators or stays a nice developer utility. That’s the signal worth tracking.