Uptime monitors call health check endpoints from outside your network, which is the only place that sees what customers see. Hyperping, for example, requests your endpoint as often as every 30 seconds from the regions you choose, counts any 2xx response as up, and alerts only after the failure is confirmed from your other regions. A text assertion can also require something like "status":"ok" in the response body, so an error page served with a 200 still counts as down.
Liveness, readiness, and startup checks
Kubernetes splits health checks into three probes, and the split is useful even if you don't run Kubernetes.
- A liveness check asks whether the process is stuck. When it fails, the container is restarted. Keep it shallow: if it checks the database and the database goes down, every pod restarts at once and nothing gets better.
- A readiness check asks whether this instance can take traffic right now. When it fails, the instance is taken out of the load balancer but keeps running. This is where checks on the database and cache belong.
- A startup check gives slow-booting applications time to start before the liveness check begins.
Kubernetes itself exposes /livez and /readyz on its API server and has deprecated its old /healthz endpoint, which is a good naming model for your own services.
Shallow and deep health checks
A shallow check returns 200 if the process can answer HTTP. It's cheap and catches crashes, but it says "healthy" when the app is running and its database is unreachable.
A deep check runs a quick query against each dependency the service can't work without, such as SELECT 1 on the database or a ping to Redis, and returns 503 if one fails. It catches more, with three rules to keep it safe:
- Give each dependency check a short timeout, one or two seconds, so a slow database doesn't make the health check hang.
- Cache the result for a few seconds. Load balancers, Kubernetes, and monitors may all call the endpoint, and each call shouldn't reach the database.
- Leave out third-party APIs. If a payment provider's outage fails your health check, your load balancer removes healthy instances and you're down too.
Use the shallow check for liveness and the deep one for readiness and external monitoring. A useful response names what was checked:
{"status":"ok","checks":{"database":"ok","redis":"ok"},"version":"2026.10.1"}
Don't put connection strings, internal hostnames, or stack traces in it. If the endpoint must stay private, require a token in a request header. Hyperping monitors can send custom headers.
Health checks and cron job heartbeats
In Hyperping, "Healthchecks" is the name of the cron job monitoring feature, and it works the other way round. Instead of Hyperping calling your endpoint, your job calls a unique Hyperping URL each time it finishes, and you get an alert when the call doesn't arrive on schedule. Use an endpoint check for services that answer requests, and a heartbeat for jobs that run on a schedule.
How to monitor a health check endpoint with Hyperping
- Add the endpoint to your app. There are step-by-step guides for Node.js with Express, Next.js, and Ruby on Rails.
- Create an HTTP monitor with the endpoint's full URL, and pick regions close to your users.
- Keep the default expected status (any 2xx), and add a text assertion such as
"status":"ok". - If the endpoint is protected, add the token as a custom request header.
- Assign an escalation policy so the alert reaches whoever is on call.
FAQ
What status code should an unhealthy service return?
503 Service Unavailable. Load balancers and monitors read the status code first, so a 200 with "status":"down" in the body only works if every caller checks the body.
Should I name it /health or /healthz?
Either works. Pick one name for every service so monitors and load balancers can be configured the same way. If you split liveness and readiness, /livez and /readyz make the difference obvious.
How often should a health check run?
Load balancers usually check every 5 to 30 seconds. For an external uptime monitor on a production service, every 30 seconds to 1 minute is the right range. At 5 minutes, an outage can last several minutes before the first failed check.
Is a ping the same as a health check?
No. A ping only shows that the host answers network packets. The web server on that host can be down, or returning errors, while the ping still succeeds. Use ping and port checks for hosts and network services, and an HTTP health check for applications.