Wall-clock uptime vs request success rate: how your SLA is actually measured

Every SLA claim rests on a single number: the Monthly Uptime Percentage. It decides whether a breach happened at all and which credit tier applies. So it is worth knowing that vendors do not compute that number the same way — and that the difference is large enough to flip a claim from valid to denied.

There are two families. Most SLAs are written in one of them, and the SLA itself tells you which, in a sentence most people skip.

Family one: wall-clock uptime

This is the intuitive one. The vendor counts the minutes in the month during which the service was unavailable, divides by the total minutes in the month, and subtracts from 100%.

Amazon EC2 is written this way. Its SLA states that Monthly Uptime Percentage is calculated by subtracting from 100% the percentage of minutes during the month in which EC2 was in the state of Unavailability. Minutes in, percentage out. If the service was down for 43 minutes in a 30-day month, that is 99.9%.

If your vendor's SLA is wall-clock, a public status page timeline is genuinely close to the contractual metric. You can add up the incident durations, do the arithmetic, and be arguing about the same quantity the vendor is.

Family two: request success rate

This one looks similar and behaves very differently. The vendor does not count minutes at all. It counts *requests*, and computes an error rate — failed requests as a share of total requests — usually within short intervals, then averages those intervals across the month.

Amazon S3 is written this way: Monthly Uptime Percentage is 100% minus the average of the Error Rates from each five-minute interval, where the Error Rate is internal server errors divided by total requests. AWS Lambda uses the same shape — availability in each five-minute interval is the percentage of requests that do not fail with a 500 or 503, and the monthly figure is the average of those intervals. CloudFront follows the S3 pattern. Grafana Cloud's 99.5% objective is likewise defined as requests succeeding, and autonomous actions such as alert evaluation and synthetic monitors completing, within the monthly billing period — not as wall-clock uptime.

Why the two numbers diverge

They are not approximations of each other. They can move in opposite directions.

A total failure during quiet hours barely registers. Suppose a service returns errors for five full minutes at 3am, and in those five minutes it receives twelve requests. All twelve fail. That interval scores 0% availability — but it is one interval among roughly 8,640 in a month, and the monthly average moves by about 0.01%. On a wall-clock reading, five minutes of hard downtime is five minutes of hard downtime.

A partial failure with the service nominally "up" can breach an SLA. Now suppose the service returns errors on 2% of requests, all month, and never once looks "down" on the status page. No incident is posted. Wall-clock uptime reads 100%. But the error-rate definition puts Monthly Uptime Percentage at roughly 98% — well past the threshold for a credit, and in some tier tables, a large one.

Averaging intervals equally weights busy and quiet ones. Because the monthly figure is the mean of the per-interval rates, a five-minute window with twelve requests counts the same as one with twelve million. That cuts both ways, and it is why the vendor's own logs are the only place the official number can come from.

What this means for a credit claim

If your vendor's SLA is a request success rate, an uptime percentage derived from its public incident timeline is not the contractual metric. It is a different quantity that happens to be expressed in the same units.

That matters because of how claims get refused. A claim that says "we measured 99.2% uptime, therefore the 10% tier applies" invites a denial on methodology — the vendor does not have to read your evidence, dispute your timestamps, or engage with the incident at all. It only has to point out that you computed something its agreement does not reference. That is the cheapest possible denial, and it costs you the filing window.

The stronger position is to stop asserting the vendor's number and ask for it instead. Do not claim the Monthly Uptime Percentage was X. State that a qualifying event occurred, give the evidence that it occurred, and ask the vendor to compute the Monthly Uptime Percentage under its own SLA definition and apply whichever credit tier follows. Offer your own downtime minutes explicitly as an indicator that a qualifying event happened — not as the contractual figure.

This is a harder request to refuse, not a softer one. The vendor cannot dismiss it on methodology, because you have not proposed a methodology. If it wants to deny the claim it has to actually run its own numbers, and under most of these SLAs it must show you the validation data if you ask.

Where you can, add the evidence that speaks the SLA's own language: your own request-level metrics for the window. Error counts and 5xx rates from your side — load balancer metrics, application logs, client-side telemetry — are the same *kind* of measurement the vendor's definition uses, even though they are your logs and not its. They will not be authoritative, and they should not be presented as if they were, but they are far more responsive to the question than a status-page duration.

How to tell which metric your SLA uses

1. Open the vendor's SLA document itself — the legal page, not a marketing page or a comparison article. The definition is almost never in the summary table.
2. Find the definition of "Monthly Uptime Percentage", "Availability", or whatever term the credit tiers are keyed to. It is usually one sentence in a definitions section.
3. Look for the words minutes, unavailable, or downtime in that sentence. If the calculation is minutes divided by minutes, you are in the wall-clock family.
4. Look instead for Error Rate, requests, successful requests, or an interval length such as five-minute intervals. If the calculation divides failed requests by total requests, you are in the request-success-rate family.
5. Note whether per-interval figures are averaged across the month, and what the interval length is — this determines how much a short, severe, low-traffic outage is worth.
6. Check for a minimum-duration floor. LaunchDarkly, for example, only counts unavailability exceeding 30 seconds, and measures availability on the user interface of your production instance with scheduled maintenance removed from both sides of the fraction.
7. Record which family it is before you ever need it. The time to discover your vendor measures differently is not the day you file.

Frequently asked questions

Does a status page tell me my SLA uptime?

Only if the vendor's SLA is written as wall-clock uptime. A status page publishes incident start and end times, which is the raw material for a minutes-based calculation. For a request-success-rate SLA — S3, CloudFront, Lambda and Grafana Cloud among them — the status page cannot produce the contractual number, because that number is computed from request logs the vendor holds and you do not.

Can I breach a request-success-rate SLA without any posted incident?

Yes. A sustained elevated error rate that never rises to a declared incident can put Monthly Uptime Percentage below the commitment while the status page stays green all month. This is the case most customers never file, because nothing ever told them to look.

Why would a short, total outage be worth so little?

Because the monthly figure is an average of per-interval error rates, and each interval counts once regardless of how many requests it carried. A five-minute total failure is a handful of intervals out of thousands. Under a wall-clock SLA the same outage is simply five minutes of downtime, which is why the same event can be worth a credit from one vendor and nothing from another.

Should I still file if I cannot compute the vendor's official number?

Yes, and quickly — filing windows are short and several are counted from the incident date rather than the end of the month. File on the evidence you have, state plainly that the official Monthly Uptime Percentage must be computed by the vendor under its own definition, and ask it to do so and apply the resulting tier. A claim you cannot perfectly quantify is still a claim; a claim filed after the window has closed is not.

Which is better for the customer?

Neither, consistently. Wall-clock is more favourable for short, severe, low-traffic outages. Request success rate is more favourable for long, partial degradation that never gets declared as an incident. What matters is not which one you prefer but which one your agreement actually says — that is the only number the vendor will pay against.

Sources

The EC2, S3, Lambda and CloudFront definitions above are transcribed from Amazon's published per-service SLAs, and the Grafana Cloud objective from the Grafana Cloud SLA, into Ontracko's vendor profiles — the same profiles that decide what each claim kit is allowed to assert. The LaunchDarkly 30-second floor is from its published SLA. Vendors revise these documents and enterprise order forms frequently override them, so verify the operative clause against your own agreement before filing. For what the percentages translate into in minutes, see what a 99.9% SLA actually allows; for who pays at all, which SaaS vendors actually pay SLA credits; for the filing clocks, SLA credit claim deadlines by vendor. Terms are defined in the SLA glossary.