What is a load balancer, and why does it matter for uptime?
A busy website is rarely one computer. It is several servers working together, and something has to decide which server answers each visitor. That something is a load balancer. It is one of the main reasons large sites can stay up when individual machines fail, and understanding it helps you plan for your own site.
What a load balancer does
A load balancer sits in front of a group of servers and receives every incoming request. It then forwards each request to one of the servers behind it. To the visitor it looks like a single site with a single address. Behind the scenes the work is spread out, so no one server is overloaded.
It gives you two benefits at once. First, capacity: you can handle more visitors by adding servers rather than buying a bigger one. Second, resilience: if one server breaks, the others carry on.
How it chooses a server
- Round robin. Requests go to each server in turn. Simple and fair when servers are similar.
- Least connections. The next request goes to whichever server is handling the fewest right now. Better when some requests take much longer than others.
- Weighted. Stronger servers get a larger share than weaker ones.
- Sticky sessions. A visitor keeps being sent to the same server, often needed when a server remembers state such as a shopping basket. It is simple but makes a server failure more disruptive for the people on it.
Health checks: the part that protects uptime
A load balancer is only useful if it knows which servers are healthy. It regularly sends small test requests to each one, usually to a simple page or a dedicated health address. If a server stops answering correctly several times in a row, the balancer takes it out of rotation and sends traffic elsewhere. When the server recovers and passes checks again, it is added back.
The quality of the health check matters more than people expect. A check that only tests whether the server is switched on will keep sending traffic to a server whose application has crashed. A better check confirms the application can reach its database and return a real answer. Be careful not to make it too heavy or too strict, or a short database hiccup can mark every server unhealthy at once and turn a small problem into a full outage.
Where load balancers sit
You will meet them at several layers. A network balancer passes connections along quickly without looking at their content. An application balancer reads each web request and can route by address, for example sending /api to one group of servers and everything else to another. A content delivery network does a similar job across the world, sending visitors to the nearest location. Large sites often use all three.
Common mistakes
- A single balancer. If the load balancer itself is one machine, it becomes the one thing that can take the whole site down. Managed services run balancers redundantly for this reason. If you run your own, run at least two.
- No spare capacity. If three servers share the load and one fails, the remaining two take on 50% more each. If they were already near their limit, the failure cascades. Plan so the site survives losing one server.
- Everything in one place. Spreading servers across several machines helps little if they all sit in the same data centre or on the same power feed. Many outages in well-known incidents came from a shared dependency, not a lone server.
- Forgetting the database. Balancing web servers does nothing if every server depends on one database that fails.
Checking it is working
Watch for uneven load, repeated server removals and slow responses from only some requests. External monitoring from outside your network, such as a monitor on your site, shows what visitors experience, which can differ from what the balancer reports. If you see errors only some of the time, a single bad server in the pool is a likely cause: see server errors 500, 502, 503 and 504 for what each response means. For how uptime figures translate into real downtime, read uptime percentages explained.
Is it down for everyone, or just you? Paste an address and we test it from fifteen places.
Open the checkerRelated guides
- How websites stay up: redundancy, failover and backups
- Uptime percentages explained: what 99.9% really means
- What is a CDN, and why do outages spread so widely?
Last updated 2 November 2026. Written by the siteupdown.com team. Spotted a mistake?
