Healthchecks.io heartbeat monitoring vs StillOnline

Healthchecks.io and StillOnline both help indie teams sleep at night — but they optimize for different shapes of failure. Healthchecks.io expects your cron job to push a ping when work succeeds; silence triggers a “missed check” alert. StillOnline pulls your HTTPS URLs on a schedule, builds a public status page, and alerts when HTTP GET fails.

Neither replaces the other in every stack. This guide is honest about gaps: StillOnline does not ship native missed-ping cron semantics out of the box — and Healthchecks.io is not a customer-facing status page product.

Quick answer

Healthchecks.io docs describe push monitoring: each job calls a unique URL on success; if a ping does not arrive within the grace period, Healthchecks emails you. StillOnline runs external HTTP GET probes (default every five minutes on Free, pricing) and publishes a status page for customers. Use Healthchecks.io (or similar) when the job must prove it ran on a tight schedule with no public HTTP server. Use StillOnline when integrators and users need “is the API up?” from outside your network — optionally adapted for cron via a heartbeat URL pattern.

Push heartbeat vs pull uptime

Healthchecks.io scheduling supports per-check period and grace — ideal for “this SQL export must finish every hour.” StillOnline asks: “does this public URL return 200 right now?”

When Healthchecks.io is the better tool

Choose push heartbeat when:

• The job runs on a worker with no inbound HTTP and you do not want a sidecar URL.
• SLA is “must complete every N minutes” — not “web server responds.”
• Failure mode is silence, not 503.
• You already email ops only — no customer status page requirement.

Example from their docs: curl -fsS -m 10 --retry 5 https://hc.example.com/unique-uuid at end of cron script.

When StillOnline is the better tool

Choose StillOnline when:

• API consumers bookmark a status page next to your docs.
• You monitor GET /health or /api/health for SaaS uptime — API-only guide.
• B2B buyers ask “where is your status page?” during procurement.
• You want one dashboard for HTTP checks + incident history + subscriber updates.

StillOnline records HTTP status code and latency — not “last ping timestamp” unless you encode that into the response contract (health endpoint design).

Bridging cron with StillOnline (no native missed-ping)

StillOnline actively GETs URLs; it does not watch for absent pushes. Patterns that work:

For queue workers without a public port, proxy heartbeat into public /health — monitoring background workers.

Side-by-side setup (typical indie stack)

Healthchecks.io

1. Create check with period + grace.
2. Append curl ping to cron entry or job footer.
3. Route alerts to email or Slack.

StillOnline

1. Create project.
2. Add HTTP check on production /health, GET, 200.
3. Share status page URL; enable Telegram owner alerts in settings.

Pro ($9/mo) on StillOnline adds up to 10 URL checks — e.g. split API vs cron heartbeat URL without replacing Healthchecks.io grace semantics.

Honest limitations

Many teams run both: Healthchecks.io for nightly billing cron silence; StillOnline for https://api.product.com/health and the customer status page.

Related guides

• Cron job heartbeat monitoring for SaaS
• API-only SaaS uptime checks
• Monitoring background workers and queues
• Health endpoint design

FAQ

Does StillOnline replace Healthchecks.io for cron jobs?

Not one-for-one. StillOnline has no native missed-ping monitor. You can approximate cron health with a reachable URL that returns non-200 when jobs stall, or keep Healthchecks.io for push heartbeats.

Can I use the same Healthchecks.io ping URL in StillOnline?

Healthchecks ping URLs expect POST/GET from the job, not continuous polling semantics. StillOnline GETs on a fixed interval — use a dedicated health or heartbeat route on your domain instead.