How websites stay up: redundancy, failover and backups

No website is up all the time. What separates a reliable site from a fragile one is how it is designed to cope when something breaks. The main ideas are old and simple: do not rely on one of anything, notice problems quickly, and practise recovering before you need to.

Single points of failure

A single point of failure is any one component whose failure stops everything. A lone web server, a single database, one internet connection, one DNS provider, one person who knows the passwords. Reliability work is largely about finding these and deciding which ones are worth removing.

Redundancy

Redundancy means having more than one of something. Two or more web servers can serve the same site, so if one fails the others carry on. Databases can have a copy that follows the main one, ready to take over. Important sites often run in more than one data centre, or even with more than one cloud provider, so a fault in one place does not take everything down.

Redundancy has a cost, in money and in complexity. More moving parts means more things to configure and more ways for the redundancy itself to fail. The aim is to remove the failures that would hurt most, not to duplicate everything.

Load balancing

A load balancer sits in front of several servers and spreads visitors between them. It also checks whether each server is healthy and stops sending traffic to any that are not. For visitors this is invisible: one address, many machines behind it.

Failover

Failover is the switch from a failed component to its backup. It can be automatic, where the system notices and moves on its own, or manual, where a person decides. Automatic failover is faster but can misfire, for example by switching when there was only a brief blip. Whichever you choose, you need to test it. A failover that has never been tried is a theory, not a plan.

Backups

Redundancy and backups solve different problems. Redundancy protects against a machine failing. Backups protect against data being deleted, corrupted or encrypted by an attacker, where a live copy would simply copy the damage. A useful backup routine has these features:

• It runs automatically and regularly.
• Copies are stored somewhere separate from the main system.
• Several older versions are kept, not just the latest.
• Someone has actually restored from one to prove it works.

Caching and content delivery

Serving saved copies of pages and files takes load off the main servers and can keep a site partly working when the origin is struggling. A content delivery network spreads those saved copies around the world. The trade-off is that you add another provider that your site depends on. See what a CDN is and why outages spread.

Graceful degradation

Even when something fails, a site does not need to fail completely. A shop can keep showing products while checkout is unavailable. A news site can serve cached articles when the comments system is down. Designing for partial failure means the loss of one feature is an annoyance rather than an outage.

The boring causes

Many outages are caused by routine things rather than dramatic failures:

• An expired certificate.
• A domain that was not renewed.
• A full disk or exhausted database connections.
• A change released with no quick way to undo it.
• A DNS record edited by mistake.

Simple habits fix most of these: automatic renewals, alerts for disk space and expiry dates, and releasing changes gradually.

Monitoring and communication

You cannot fix what you do not know about. Monitor your site from outside your own network, with alerts that go to more than one person and do not depend on the same provider as the site. Our monitoring guide explains how, and a free account here can watch your sites and email you when one goes down or recovers.

When something does go wrong, tell people. A short, honest status update early on is worth more than a perfect explanation hours later. See how to write an outage update.

What uptime numbers mean

Availability is usually quoted as a percentage. 99.9% sounds high but allows about 8 hours and 45 minutes of downtime a year, or about 43 minutes a month. 99.99% allows under an hour a year. Each extra nine is much more expensive than the one before. Our guide to uptime percentages shows what each level means in minutes, and the uptime SLA calculator does the arithmetic for you.

A sensible order of priorities

1. Automatic renewals and expiry alerts.
2. Tested backups kept off the main system.
3. Outside monitoring with alerts to more than one person.
4. A way to roll back a bad change quickly.
5. Redundancy for the components that hurt most when they fail.
6. A written plan for who does what in an incident.

Related guides

• Why big websites go down: cloud, CDN and DNS failures
• Uptime percentages explained: what 99.9% really means
• How to monitor your own website: what to check and how often

Last updated 2 November 2026. Written by the siteupdown.com team. Spotted a mistake?

← All help guides