Blog · Monitoring

Cron monitoring, heartbeats and uptime checks

An uptime monitor catches the 500. A heartbeat catches the silence. These posts cover both halves of the failure space and how to monitor scheduled work without a second bill.

About this topic

Monitoring

5 itemsBlog

An uptime monitor watches whether a URL responds correctly. A heartbeat watches whether a URL got pinged at all. The first catches loud failures (your app returns a 500). The second catches the silent ones (the cron didn't fire, the worker is dead, the deploy turned the schedule off). For anything serious you usually want both, but on different things: uptime on customer-facing URLs, heartbeats on periodic backend work.

Crontap covers both in one dashboard. Built-in uptime monitoring runs from 1 minute to 24 hours, with 90 days of green and red bars and email alerts on the up-to-down transition. Failure alerts on every schedule fire to Slack, Discord, Telegram, email, or a webhook the moment a 4xx or 5xx comes back. For dead-man checks on absence, pair with Healthchecks.io (the canonical shape) or run a second Crontap schedule that pings a heartbeat URL. The posts below cover the heartbeat-vs-uptime decision, the Healthchecks.io pairing, the UptimeRobot alternative, and the Cronhub shutdown migration.

Blog on Monitoring

5 items

Related on Crontap

The same Monitoring topic, from other angles.

FAQ

Common questions on Monitoring

Heartbeat or uptime monitor for my nightly cron?
Both, on different things. Put an uptime monitor on the customer-facing endpoint that the cron might cause to misbehave. Put a heartbeat on the cron itself so you find out the moment it stops firing, not the morning after the digest didn't land.
Cronhub is shutting down. What's the migration path?
Paid subscriptions are cancelled May 31, 2026, and schedules and ping history are deleted June 30, 2026. The dedicated migration post walks the move for both halves of Cronhub (scheduler to Crontap, heartbeats to Healthchecks.io or a second Crontap schedule that pings).
How is Crontap's built-in uptime different from UptimeRobot?
Crontap runs uptime on the same dashboard as the schedules that hit those URLs. UptimeRobot is uptime-only, which is fine if that's the only thing you need. If you also run scheduled HTTP work, the wedge is one tab, one bill, one alert routing.
What cadence makes sense for an uptime check?
One minute for anything customer-facing. Five minutes is fine for internal services. Slower than that and you risk missing short outages entirely.

More from Crontap

Topics across the site.

Every topic Crontap covers, in one row. Each one has its own page on the blog surface.

Ready to fix it?

Point Crontap at any URL. Pick any cron. Done.

WordPress, Shopify, Railway, Cloud Run, Vercel, HubSpot, Ghost, your own box. If it answers HTTP, Crontap can drive it on a clock you can read, in the timezone that actually matters, and page you when something breaks.

Free forever tier ・ No credit card required

GET

/wp-cron.php?doing_wp_cron=1

Running
Your next schedule

Schedule

"every 5 minutes"

Next

in 23s