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

11 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. Uptime monitoring runs from 1 minute to 24 hours, with 90 days of green and red bars and alerts on the up-to-down transition. Native Heartbeats use period plus grace, accept /fail, keep 90 days of event history, and route to connected notification channels plus optional generic webhook Integrations. The posts below cover the heartbeat-vs-uptime decision, the independent Healthchecks.io pattern, the UptimeRobot alternative, and the Cronhub shutdown migration.

Blog on Monitoring

11 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 shut down. What's the migration path?
Cronhub closed June 30, 2026. The dedicated migration post walks both halves: schedules move to Crontap Schedules and heartbeat monitors move to native Crontap Heartbeats.
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