An online store can lose every sale for an hour while its virtual machines continue to accept network connections. If the payment service is broken, the infrastructure provider's VM uptime measurement may never register the outage. The shop's customers certainly will.

This is the difference between a service-level agreement (SLA) and the availability of an entire business application. The SLA defines what the supplier covers and the contractual remedy when it misses that commitment.

Read the service definition before the percentage

The Amazon Compute SLA has separate commitments for qualifying multi-availability-zone EC2 deployments and individual instances. The regional commitment also addresses a cross-region arrangement when a region has only one zone. The terms define unavailability using connectivity and specify the covered arrangement.

Google Compute Engine's SLA likewise distinguishes deployment configurations, network tiers and regions. Its covered events include loss of external connectivity or persistent-disk access for relevant VM services. Load balancing has its own coverage. Even within one provider, a percentage is not a universal promise covering every machine type and service.

Check the current contract for your actual product and deployment. Definitions, exclusions and measurement windows can matter more than a difference between two advertised percentages. Negotiated agreements may differ from published standard terms.

How much downtime is four nines?

A 30-day month contains 43,200 minutes. For a simple time-based availability calculation:

  • 99.9% leaves 43.2 minutes outside the target.
  • 99.95% leaves 21.6 minutes.
  • 99.99% leaves 4.32 minutes.

These figures are arithmetic examples, not an interpretation of every provider's SLA. Some contracts exclude short events or define downtime over particular intervals. The actual calculation can also exclude specific causes.

The pattern of failure matters. Ten minutes during a sales launch may cost more than an hour overnight. A regional problem may affect only a fraction of customers. Measuring minutes alone can conceal both effects.

Measure what the application promises

For an application, a request-based availability metric is often more useful. If 995,000 out of one million eligible requests succeed, the observed success rate is 99.5%. Under a 99.9% request-based objective, the error budget for that interval would be 1,000 failed requests. Five thousand failures consume five times the budget.

The metric needs a definition of success. A response with HTTP 200 that says payment failed may not count as a successful transaction. A response arriving after the user's deadline may also be a failure for the service even if the server eventually completes it.

Google's Site Reliability Workbook explains how service-level indicators and objectives can reflect user-visible behavior. The provider SLA is one input to the application's own objective. An operator should measure important customer actions directly rather than use the supplier's VM uptime as a substitute.

What a credit is worth

Imagine a supplier grants a 10% service credit on $500 of eligible monthly charges. The credit is $50, assuming the incident qualifies and all $500 falls within the covered amount. The hypothetical shop may have lost thousands of dollars in revenue. The two values describe completely different things.

The Amazon Compute SLA and Google Compute Engine SLA specify how credits are calculated and claimed. Credits are generally tied to eligible service charges and applied according to the agreement, not automatic reimbursement of lost revenue or staff time. Record the claim deadline, required evidence and any exclusions when evaluating the service.

A supplier offering a larger percentage credit is not necessarily more reliable. That credit is a financial remedy; the reliability claim is defined elsewhere in the agreement. A business may need separate arrangements for risks the SLA does not transfer.

Use the SLA in the architecture decision

If the business requires 99.99% availability for checkout, an individual infrastructure contract with the same percentage does not prove checkout will meet that target. Authentication, databases, payment systems and the application itself all contribute to the result.

Even two independent dependencies that must both succeed, each with 99.9% availability, would have a combined availability of about 99.8001% under a simplified independent-failure model. Real dependencies may share failure causes, so multiplying percentages is not a reliable production forecast.

Keep three records: the user's experience, the application's SLO result and the supplier's SLA calculation. Each serves a different purpose. The architecture behind those measurements is covered in cloud regions and availability zones.