High availability (HA) is the practice of designing systems so they keep running when individual components fail. Instead of trying to prevent every failure, an HA design duplicates the parts that can break, such as servers, storage, power, network links and firewalls, and switches to a healthy copy automatically, so users ideally see no interruption or only a brief one. Availability is usually expressed as a percentage of uptime, such as 99.9% or 99.99%, and each step up costs more to achieve.
At a glance
- HA removes single points of failure by duplicating critical components and failing over automatically.
- It aims to keep service running or restore it within seconds to minutes; it does not make failures impossible.
- Availability targets are often expressed in “nines”: 99.9% allows about nine hours of downtime a year, 99.99% about 52 minutes and 99.999% about five minutes.
- HA covers everyday failures within a site or region; disaster recovery covers losing a whole site or region.
- A provider’s uptime SLA commits to a target with service credits; it is not a guarantee of availability.
What problem it solves
Every system has parts that eventually fail. Disks wear out, power supplies die, software crashes, network links get cut, and maintenance requires restarts. When a critical application depends on a single server, firewall or internet connection, any one of those events becomes an outage: orders stop, phones go quiet, and staff sit idle.
High availability turns those failures into non-events, or at least short ones. By identifying every single point of failure and putting a redundant component behind it, an HA design lets the business keep working while the broken part is repaired. It also allows planned maintenance, such as patching one server at a time, without scheduling downtime.
How it works
Redundancy. Critical components are duplicated, often to an N+1 standard, meaning at least one spare beyond what is needed. That can include servers, storage controllers, power supplies, cooling, network switches, firewalls and internet links from different carriers.
Clustering and failover. Servers or appliances are grouped so that if one fails, another takes over its work. In an active-passive design a standby waits to take over; in an active-active design all members carry load and the survivors absorb the extra work. Failover may be instant or take seconds to minutes, depending on the technology.
Load balancing. A load balancer spreads traffic across several servers and stops sending it to any that fail health checks.
Data replication. Replication keeps copies of data on more than one system, either synchronously (no data lost on failover, but sensitive to distance) or asynchronously (some recent data may be lost).
Monitoring. Health checks detect failures and trigger failover, and alerts tell the team that a component needs repair before a second failure hits.
In the cloud, HA usually means spreading an application across more than one availability zone. On the network side, SD-WAN can provide HA for site connectivity by running two or more internet links and moving traffic when one fails.
When it matters for buyers
- When setting availability targets. Not every system needs four or five nines. Match targets to the real cost of downtime for each application, because each extra nine adds cost and complexity.
- When reading SLAs. A service level agreement (SLA) states the provider’s commitment and the credits you get if it is missed. Check how availability is measured, what is excluded, such as planned maintenance, and whether the credits are meaningful.
- When buying infrastructure. Clustered servers, hyperconverged systems, redundant firewalls and dual internet links are often quoted as options; confirm they are included.
- When moving to the cloud. HA depends on your architecture, not just the provider’s.
- When testing. Untested failover often fails. Schedule failover tests, not just backups.
Questions to ask vendors
- What availability do you commit to, how is it measured and what is excluded?
- Which components in this design are redundant, and what single points of failure remain?
- How long does failover take, and is any data lost during it?
- Do redundant components share anything that could fail together, such as power, a building, a carrier’s network or a software version?
- How do you handle maintenance and upgrades without downtime?
- How often do you test failover, and can we see the results?
- What are the credits if you miss the SLA, and how do we claim them?
How it differs from Disaster Recovery
High availability keeps a service running through component failures, typically within one data center, cloud region or site, and fails over in seconds to minutes. Disaster recovery restores service after an event that takes out a whole site or region, such as a fire, flood, regional outage or ransomware attack, and is measured by recovery time and recovery point objectives that are usually longer. HA alone doesn’t protect you from losing the site, and disaster recovery alone means waiting through recovery for problems HA could have absorbed. A business continuity and disaster recovery (BCDR) plan usually combines both, sometimes using disaster recovery as a service (DRaaS) for the second site. Our private cloud page covers how HA is built into hosted infrastructure.
Problems this helps with
- One server or firewall failure takes the whole business offline
- Planned maintenance means scheduling downtime every month
- Not sure what uptime our applications actually need, or what it would cost
- Provider's uptime SLA doesn't match what we were told about redundancy
