What is the difference between a liveness and a readiness check?

A liveness check confirms the process is running and accepting connections at all. A readiness check goes further and confirms the service can actually serve traffic, often by verifying it can reach its database and dependencies first. A service can be live but not ready, for example during startup or when a downstream system is down.

How often should a health check run?

For uptime monitoring, a 1-minute interval is common because it caps your worst-case detection delay at roughly one minute. Less critical endpoints are often checked every 5 minutes to reduce noise and load. The interval directly sets how quickly you learn about an outage.

Why run health checks from outside your own servers?

A server can consider itself healthy while DNS, networking, a CDN, or an expired certificate still makes it unreachable to real visitors. Probing from external locations, the way a visitor connects, captures the experience that actually matters and is the basis of an accurate uptime measurement.

What HTTP status code should a healthy check return?

Typically 200 OK, returned within the configured timeout. Many checks also inspect the response body or a specific field so a page that returns 200 but renders an error is still caught. Any timeout, connection failure, or 4xx/5xx response usually counts as a failed check.

What Is a Health Check?

Reviewed by Ionut Caval · Updated June 2026

A health check is an automated probe of an endpoint that reports whether a service is up and working correctly. It is the basic unit of uptime monitoring: one request, sent on a schedule, whose response decides whether the service counts as healthy or failed.

A health check sends a request to a known endpoint and judges the answer against a set of expectations. The simplest version confirms a URL returns HTTP 200 within a timeout. A stricter check also inspects the response body, validates a JSON field, verifies the TLS certificate, or asserts that the request completed under a latency limit such as 500 ms. Whatever the rules, the check produces a binary verdict every time it runs (healthy or unhealthy), and a sequence of those verdicts over time is exactly what your uptime percentage is built from.

What a health check verifies

How thoroughly a check probes the service decides what it can catch. A request can succeed at the network level while the application behind it is broken, so deeper checks trade a little cost for far better coverage. Common levels include:

Liveness: is the process running and accepting connections at all? Confirms the endpoint responds, nothing more.
Readiness: is the service actually able to serve traffic? Often verifies it can reach its database, cache, or downstream dependencies before reporting healthy.
Deep or synthetic: does a real user flow work? Steps through login or checkout and asserts the expected result, catching failures a status code alone would miss.

The interval sets how fast you find out about a problem. A check that runs every minute caps your worst-case detection delay at roughly 60 seconds; a 5-minute interval can leave a failure unnoticed for up to five minutes. Most tools also require a small number of consecutive failures (for example two or three) before declaring an outage, so a single dropped packet from one location does not trigger a false alarm.

Why checks run from outside your infrastructure

A service can report itself as healthy while DNS, an expired certificate, a CDN, or a broken route still makes it unreachable to real visitors. That is why uptime checks run from external locations, the way a visitor connects, rather than from the server's own view of itself. Running the probe from several regions also separates a genuine outage from a local network blip. This is the engine of synthetic monitoring, and it complements heartbeat monitoring, where a job pushes a signal out on a schedule and an alert fires if the expected heartbeat never arrives.

Health checks are the raw measurement everything else rests on. Their pass and fail results feed your uptime figure, flip a public status page to a degraded or outage state the moment a check fails, and trigger the alert that starts the clock on recovery. For where this fits alongside field performance data, see synthetic monitoring vs real user monitoring. Pulsetic's uptime and API monitoring runs these checks from multiple regions so a single local glitch is not mistaken for a real outage.

Frequently asked questions

What is the difference between a liveness and a readiness check?

A liveness check confirms the process is running and accepting connections at all. A readiness check goes further and confirms the service can actually serve traffic, often by verifying it can reach its database and dependencies first. A service can be live but not ready, for example during startup or when a downstream system is down.
How often should a health check run?

For uptime monitoring, a 1-minute interval is common because it caps your worst-case detection delay at roughly one minute. Less critical endpoints are often checked every 5 minutes to reduce noise and load. The interval directly sets how quickly you learn about an outage.
Why run health checks from outside your own servers?

A server can consider itself healthy while DNS, networking, a CDN, or an expired certificate still makes it unreachable to real visitors. Probing from external locations, the way a visitor connects, captures the experience that actually matters and is the basis of an accurate uptime measurement.
What HTTP status code should a healthy check return?

Typically 200 OK, returned within the configured timeout. Many checks also inspect the response body or a specific field so a page that returns 200 but renders an error is still caught. Any timeout, connection failure, or 4xx/5xx response usually counts as a failed check.

Put these metrics to work. Monitor your site free.

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed