If a load balancer goes down, the company's entire web traffic grinds to a halt. HAProxy high availability is designed specifically to prevent this scenario, yet it is often the least redundant component in an entire infrastructure—the one quickly installed to distribute load and then forgotten.
Consider a fairly standard multi-service environment: an HAProxy frontend routing HTTPS traffic to several business applications, such as a payment site, an intranet, an HR app, and a few internal web services. All this traffic passes through a single machine.
The day that machine fails, access to all services disappears simultaneously while teams scramble to understand what is happening. In this type of infrastructure, doubling up application servers is useless if the load balancer in front of them remains a single point of failure (SPOF).
To mitigate this risk, setting up a cluster of two load balancers—one active, one passive, with automatic failover if the first node goes down—is essential. Technically, there are several options: heartbeat, keepalived, or VRRP. In our case, we use heartbeat, which allows for a floating IP address (the VIP) shared between the two nodes. The active node holds it; if it stops responding, the passive node takes over, along with the HAProxy service.
The detail that changes everything is the network used for communication between the two nodes. Many setups route Heartbeat packets over the standard production network. Congestion can make a node think its neighbor is dead when it is simply responding more slowly, triggering an unnecessary failover. The best practice is to isolate this communication on a dedicated, point-to-point link between the two machines.
A second detail often overlooked is how to verify that a backend server is alive. A simple TCP check only verifies that the port is responding. An HTTP application health check, which queries a dedicated route and verifies the return code, detects a server that is responding to the network but crashing internally. This is the difference between "the service is running" and "the service is actually working."
Encryption deserves the same care: a hardened TLS profile based on the Mozilla SSL Configuration guide, and HSTS headers forced on all responses. A poorly configured load balancer in terms of TLS remains an entry point as vulnerable as any application server.
An SME or an IT department managing several critical internal business applications should consider implementing a redundant LB infrastructure. A non-redundant load balancer turns any reboot, update, or hardware incident into a total service outage.
There is a second, less visible challenge: once you switch to a cluster, debugging becomes more complex. If a failover has occurred, you have to retrieve logs from both nodes to reconstruct what happened. Centralizing logs should be part of the project from the very beginning.
For a multi-site retail architecture we supported, the HAProxy load balancer handled HTTPS traffic for several distinct business applications (payment, intranet, internal web services), routed by hostname on a single frontend. We deployed two nodes in production with heartbeat, and two others in pre-production to validate changes before failover.
Even before setting up the second machine, we created a virtual network dedicated solely to Heartbeat traffic, with a point-to-point interface on each node. TLS was hardened according to Mozilla's "intermediate" profile, with HSTS forced on all responses. Health checks were switched to HTTP application checks rather than simple TCP for all critical backends.
The real gain came from the logs. HAProxy logs, generated in structured JSON format, are now centralized via rsyslog in an encrypted stream to a log management platform like Graylog, with parsing via Grok patterns to find any request, on any node, in seconds.
Isolate the Heartbeat network at the design stage, never as an afterthought, to avoid phantom failovers. Prefer application health checks over simple TCP checks for all backends that carry business logic. Centralize logs before the cluster grows, not at the moment of the first incident that is difficult to reconstruct.
And one issue we still see too often: an admin password left in plain text in a configuration file, providing access to the HAProxy statistics page. A password manager combined with source IP access restrictions is far better than a simple basic auth left forgotten in a config file that never gets reviewed.
A high-availability load balancer is not just "two servers instead of one." It is an isolated failover network and logs that you can actually use when things go wrong. The real question isn't whether your frontend might fail, but what actually happens the day it does.
