HAProxy Health Check Config: Examples and Gotchas

An HAProxy health check is a probe the load balancer runs against each backend server to decide whether it still belongs in rotation. Add check to a server line and HAProxy starts testing it every two seconds. The defaults are sensible, but they are also the reason a failing backend can keep serving errors for six seconds longer than you expected.

Enabling an active HAProxy health check

Put check on the server line and nothing else changes. HAProxy opens a TCP connection to the server's IP and port on a schedule, and marks it DOWN once enough attempts fail in a row.

backend api_servers
    balance roundrobin
    server api1 10.0.1.11:8080 check inter 2s rise 2 fall 3
    server api2 10.0.1.12:8080 check inter 2s rise 2 fall 3

Those three parameters are written out here because the defaults are easy to forget. The vendor's configuration tutorial documents them, along with the passive and agent variants covered further down.

What do rise, fall and inter actually do?

They decide how long a broken server keeps receiving traffic. inter is the gap between checks, fall is how many consecutive failures mark a server DOWN, and rise is how many consecutive successes bring it back.

Parameter	Default	Meaning	Worst-case effect
inter	2s	interval between checks	detection granularity
fall	3	failures before DOWN	6s of errors at the default
rise	2	successes before UP	4s before a recovered server returns
fastinter	inter	interval in a transitional state	speeds up detection mid-flap

At the defaults, a dead backend keeps taking requests for roughly six seconds. We prefer fall 2 with inter 1s for stateless HTTP backends, which halves that, and a slower rise of 3 so a flapping server has to prove itself before it gets traffic again.

timeout check deserves its own line. Without it the proxy falls back to the connect timeout, which is far longer than a probe should ever wait. Set it above your backend's measured p99 and below the interval, so a slow response fails the check instead of overlapping the next one.

fastinter is the parameter almost nobody sets. It replaces inter while a server sits in a transitional state, so a suspected failure is confirmed quickly without extra load the rest of the time. Pairing inter 2s with fastinter 500ms tightens detection without quadrupling the check volume.

Making the check HTTP aware

A bare TCP check only proves something accepted the connection. The process behind it can be wedged, out of database connections, or returning 500 to every request, and the socket still opens. This is the same limitation that applies to any transport-layer test, and it is covered in more depth in our guide to port monitoring.

Two directives fix it:

backend api_servers
    option httpchk GET /health
    http-check expect status 200
    server api1 10.0.1.11:8080 check inter 1s fall 2 rise 3

Point option httpchk at an endpoint that touches what actually matters. A /health route that returns 200 unconditionally is decoration. One that verifies a database connection and a cache round trip is a real readiness signal, and it is what http-check expect should be matching against.

HTTPS backends need one more flag

Checks against a TLS backend fail by default, because HAProxy speaks plaintext to the check port unless told otherwise. Add check-ssl, and add verify none when the backend uses an internal certificate that the proxy has no CA for.

    server api1 10.0.1.11:8443 check check-ssl verify none inter 1s fall 2

Skipping verification is a deliberate trade. Inside a private network it is usually acceptable, and Akamai's HAProxy guide walks through the alternative of pointing HAProxy at a CA bundle instead. Pick one consciously rather than copying the first Stack Overflow answer.

Passive and agent checks

Active checks generate traffic whether or not anyone is using the service. Passive checks watch real requests instead and mark a server down after too many errors:

    server api1 10.0.1.11:8080 check observe layer7 error-limit 10 on-error mark-down

The trade with passive checks is that they need traffic to work. On a quiet backend an error limit of 10 can take minutes to trip. Most setups run observe alongside an active HAProxy health check rather than instead of one.

Agent checks are a third channel. The server runs a small responder on agent-port that reports its own weight, so a machine can drain itself before a deploy rather than waiting to fail a probe. The HAProxy blog guide covers the protocol and the agent-inter timing.

The blind spot nobody mentions

Here is the thing every HAProxy health check has in common: it tells you what the proxy thinks about its backends. It says nothing about whether a user can reach the proxy.

When the VIP fails over badly, the TLS certificate on the frontend expires, or keepalived hands the address to a node with a stale config, every backend is still green. The stats page shows a healthy pool. The site is down.

Only a check from outside the network sees that. It has to run from more than one location, because a routing problem often affects one region and leaves another untouched.

Uptime Room probes from six regions as of September 2026, and the egress IPs are published on the probe IPs page so you can allowlist them on the frontend. Watching the same hostname your users type is the whole point. The four golden signals apply to the proxy exactly as they do to the services behind it.

Common mistakes

Pointing the check at /. The homepage often survives a database outage because of caching. Give the check its own route with no cache headers and a real dependency test behind it.

Leaving the defaults on a slow backend. A check timeout shorter than the backend's normal p99 marks healthy servers DOWN under load. Set timeout check explicitly and base it on measured latency, not a guess.

Treating the stats page as an alert. /haproxy?stats;csv is a good scrape target, but nothing pages you when the process that serves it dies. That gap is what external uptime checks exist to close.

A well-tuned HAProxy health check keeps traffic off broken backends in about two seconds, using an endpoint that tests something real. Pair it with a check from outside the network so a frontend failure cannot hide behind a green stats page. The free plan covers 10 monitors at a one-minute interval as of September 2026. That is enough for a VIP and its public hostnames, so start free and close the gap.