High availability (HA) is the ability of a system to remain usable for its users despite failures of individual components. It is achieved by redundancy, automatic failover, health checking and the removal of single points of failure, and is usually expressed as an availability target such as 99.9 % or 99.99 % over a defined period.
What is high availability?
High availability describes systems designed so that the failure of a server, a disk, a zone or a process does not make the service unavailable to users. Instead of trying to build components that never fail, HA architectures assume that failures will happen and make sure another instance takes over quickly, ideally without anyone noticing.
Availability is measured as the share of time, or of requests, during which the service works as expected. It is closely related to uptime, but a high-availability design is about the mechanisms behind the number: redundancy, failure detection and recovery.
The math of nines
Availability targets are often stated in "nines". The table shows the maximum downtime each level allows, calculated from the percentage:
| Availability | Downtime per year | Downtime per 30 days |
|---|---|---|
| 99 % | about 3.65 days | about 7.2 hours |
| 99.9 % | about 8.76 hours | about 43 minutes |
| 99.99 % | about 52.6 minutes | about 4.3 minutes |
| 99.999 % | about 5.3 minutes | about 26 seconds |
Two rules of thumb follow from probability. Components in series multiply: a service that needs two dependencies at 99.9 % each can reach at most about 99.8 %. Components in parallel combine as 1 minus the product of their failure probabilities: two independent replicas at 99 % give about 99.99 %. The catch is the word independent; replicas in the same zone, with the same configuration or the same bug, tend to fail together.
Common high-availability patterns
- Active-active: several instances serve traffic at the same time behind a load balancer. A failed instance is removed from rotation and the others absorb its load.
- Active-passive: a standby takes over when the primary fails, common for databases such as PostgreSQL with streaming replication. Failover time and data loss on switchover are the key parameters.
- N+1 or N+2 capacity: enough spare capacity to lose one or two instances, zones or nodes without overload.
- Multi-zone and multi-region deployment to survive the loss of a data center or a whole region.
- Quorum-based consensus (for example Raft in etcd) so that a cluster keeps working as long as a majority is reachable and avoids split brain.
- Graceful degradation through timeouts, retries with backoff and a circuit breaker, so a failing dependency does not take down the caller.
Failure detection and failover
Redundancy only helps if failures are detected and acted on. Load balancers and orchestrators rely on health checks to remove unhealthy instances. The detection interval, the number of failed checks required and the time to promote a standby together determine how long users are affected. Checks that are too sensitive cause flapping; checks that only test "process is running" miss instances that are up but broken.
Changes are the other big risk. Many outages are caused by deployments or configuration changes rolled out to all replicas at once, which removes the benefit of redundancy. Progressive rollouts such as canary deployments limit the blast radius.
Example: a simple HA web service
An illustrative setup: three application replicas in three availability zones behind a load balancer, a primary database with a synchronous standby in a second zone, and a readiness probe that checks the database connection. If one zone fails, two replicas keep serving; capacity is sized so two replicas can handle peak traffic. If the database primary fails, the standby is promoted and applications reconnect. The team tests this regularly by terminating a replica and triggering a database failover in a staging environment, measuring the time until error rates return to normal.
Monitoring high availability
- Measure availability from the user's perspective with request success rates and synthetic monitoring from several locations.
- Define an availability SLO and track the error budget instead of chasing an abstract number of nines.
- Alert on lost redundancy, for example a replica set running below its desired count, before the next failure turns it into an outage.
- Record failover events and their duration, and review them in postmortems.
How Obseria helps
Obseria combines synthetic checks, SLOs with burn-rate alerts and status pages, so you can see whether redundancy actually protects users and communicate when it does not. TopoGraph shows which dependencies a service relies on, which helps to spot single points of failure. Contractual commitments are covered under SLA.
