Cronheart Reviews and Details

Questions & Answers

1. What makes Cronheart unique?

   Cronheart watches scheduled jobs with a dead-man's switch: every run sends one HTTP ping, and if a ping doesn't arrive on time you're alerted within seconds — so it catches the job that silently never ran, not just one that errored (which uptime monitors miss, because the server is still up). It's deliberately tiny: a single curl works from any language or platform, with optional start/success/fail signals, up to 10KB of captured output on failures, and alerts to email, Telegram, Slack, Discord, and signed webhooks. PHP and WordPress teams also get first-class integrations — a Symfony and Laravel SDK and a WP-Cron plugin — but none are required.

2. Why should a person choose Cronheart over its competitors?

   Flat, predictable pricing and a focused product. The free tier covers 20 monitors with no credit card; paid is $5/mo for 50 and $19/mo for 200 — no per-monitor metering that climbs as you add jobs. Cronheart does cron and heartbeat monitoring well instead of bolting it onto a broad observability suite, so setup is one curl in about five minutes and alerts fire within ~30 seconds. It also reports explicit start/success/fail (a crashed or hung run pages you immediately, not just a missed window), and offers first-class PHP and WordPress integrations that language-agnostic tools don't.

3. How would you describe the primary audience of Cronheart?

   Developers, SREs, and DevOps/ops teams who run scheduled jobs — cron, systemd timers, framework schedulers, CI pipelines, WP-Cron — in any language or stack and need to know the moment one stops running. It fits everyone from solo developers and small teams on the free tier up to teams watching hundreds of jobs. PHP and WordPress shops get the smoothest onboarding through the SDK and plugin, but it's used from any platform that can make an HTTP request.

4. What's the story behind Cronheart?

   Cronheart grew out of a familiar blind spot: a cron job quietly stops running and nobody notices until something downstream breaks — a backup that didn't happen, a report that never went out, a queue that stalled. Uptime monitors don't catch it, because the site is still responding; the job just isn't firing. Cronheart was built to turn that into an alert — a dead-man's switch for scheduled jobs that takes one curl to add and behaves the same on any stack.

5. Which are the primary technologies used for building Cronheart?

   The backend is PHP 8.3 on the Symfony framework, with Doctrine and MySQL 8 for storage. Pages are server-rendered with Twig plus a single small vanilla-JS file — no front-end framework or build step — and it runs on a standard Apache + php-fpm stack. The ping endpoint and REST API are plain HTTP, so clients integrate from any language without an SDK.