Availability Targets and SLOs

Availability targets define measurable reliability objectives for a service, such as the percentage of requests that should succeed. An SLO turns that target into an explicit operational goal and makes the acceptable amount of failure or downtime measurable.

An SLI (Service Level Indicator) is the measurement used to describe service behavior, such as successful requests divided by total valid requests. An SLO (Service Level Objective) is the target applied to that measurement, for example, 99.9% successful requests over a defined period.

Availability targets can be expressed as request success rates or as uptime. A 99.9% availability target permits about 0.1% unavailability during the measurement window. The corresponding error budget is the amount of unreliability the service can tolerate while still meeting the SLO.

An SLA (Service Level Agreement) is different from an SLO. An SLA is a formal agreement, often with customers, that can specify consequences when commitments are missed. An internal SLO can instead guide engineering decisions without creating a contractual obligation.

For a Java backend, availability should be measured at the service boundary rather than inferred only from process health. A JVM can be running while requests fail because of database errors, dependency outages, timeouts, or resource exhaustion. The chosen SLI should therefore reflect what users actually experience.

Availability targets are useful for both high availability and disaster recovery planning. A stricter target generally requires stronger redundancy, monitoring, failover, capacity planning, and recovery mechanisms. The target should be chosen based on business impact and realistic engineering cost rather than simply maximizing the number of nines.

Key points

• SLI measures reliability; SLO defines the target for that measurement.
• Availability can be measured as successful requests over total applicable requests.
• An error budget represents the allowed unreliability under an SLO.
• An SLA is a formal commitment, while an SLO is an operational objective.
• Higher availability targets usually require more redundancy and stronger recovery mechanisms.

Interview questions

What is an SLO, and how is it different from an SLI?

An SLI is a metric that measures an aspect of service behavior, such as request success rate. An SLO defines the desired value or range for that metric over a specified period. For example, successful requests could be the SLI, while a goal of 99.9% success could be the SLO. The distinction is measurement versus objective.

What does 99.9% availability mean?

It means the service is expected to satisfy the defined availability criterion for 99.9% of the measurement period or applicable requests. The remaining 0.1% is the permitted unavailability or failure budget under that definition. The exact interpretation depends on whether availability is measured by time, requests, or another agreed SLI. The measurement window must therefore be stated.

What is an error budget?

An error budget is the amount of unreliability allowed by an SLO before the service falls outside its objective. For a 99.9% success target, roughly 0.1% of the relevant measurement can be consumed by failures. Teams can use the budget to balance reliability work against feature delivery. If the budget is being exhausted too quickly, engineering priorities may shift toward reliability.

Why is application-level availability often better than simply monitoring whether a JVM is running?

A running JVM only shows that the process exists; it does not prove that users can successfully complete requests. The application may be unable to reach a database, dependency, cache, or external service while the process remains healthy. An application-level SLI can capture successful responses and therefore better represent user-visible availability. Process-level health checks are still useful, but they answer a narrower question.

How do availability targets affect disaster recovery design?

Availability requirements influence how much redundancy and recovery capability a system needs. A service with a demanding availability objective may require multiple instances, independent failure domains, automated failover, and carefully tested recovery procedures. Disaster recovery also depends on recovery objectives such as RTO and RPO, which address restoration time and acceptable data loss. The correct architecture is therefore driven by business requirements rather than by availability numbers alone.