How to calculate SLA credits, with worked examples

SLA disputes are rarely about whether an outage happened. They are about the arithmetic: which minutes count, which month they fall in, whose measurement is right and what happens when the measurement itself is missing. This guide works through the formula, then the contract terms that change the answer, with numbers you can check by hand.

The formula

Attainment is the share of eligible time the service was available:

attainment = (eligible minutes − downtime minutes) ÷ eligible minutes × 100

Eligible minutes are the minutes in the period minus anything the contract excludes, usually scheduled maintenance. Downtime minutes are the minutes that meet the contract's definition of unavailable. The credit is then looked up from a tier table and applied to that period's fee.

Months are not the same length, so the same target allows a different amount of downtime in February than in March:

Figures are rounded to the nearest second. A 30-day month has 43,200 minutes, so 99.9% allows 43.2 minutes of downtime.

Example 1: one outage

The contract promises 99.9% per calendar month, for a fee of $4,000 a month, with these credit tiers:

In a 30-day month the service is down for 52 minutes. Attainment is (43,200 − 52) ÷ 43,200 = 99.8796%. That is below 99.9% but not below 99.0%, so the credit is 10% of $4,000, or $400.

That is the easy case. Every term below can change the result for the same outage.

Example 2: maintenance that runs over

Same contract, same 30-day month. A planned maintenance window is scheduled for 60 minutes and runs 20 minutes over. Separately, there is a 25-minute outage. Whether the contract excludes the scheduled window or the actual maintenance decides the outcome:

Same month, same events, opposite answers. Neither rule is wrong, but the contract has to name one. Excluding only the scheduled window is the stricter rule for the provider, because it stops a maintenance window from quietly absorbing an outage. Contracts often also require advance notice before a window counts as scheduled at all.

Example 3: slow is not the same as down

Forty minutes of hard failure is easy to classify. Ninety minutes of checkout taking eight seconds is not. Suppose a 30-day month has 40 minutes where the service was unhealthy and 90 minutes where it was degraded:

If the contract only says "availability", expect each side to read it differently. Write down what degraded means for each service (for example "p95 latency above 2 seconds") and whether it counts against the target.

Exactly on the line

A 30-day month at 99.9% allows 43.2 minutes, which is 43 minutes and 12 seconds. With exactly that much downtime, attainment is exactly 99.9000% and the target is met, provided the tier says "below 99.9%". With 43 minutes and 30 seconds, attainment is 99.8993%. Rounded to two decimals, that displays as 99.90%, yet it is below the threshold and a credit is owed.

This is a classic source of disputes, and it has two fixes. State that tiers apply when attainment is strictly below the threshold, and compare at full precision (or a precision the contract names) instead of comparing rounded numbers.

Tiers are not added together

At 98.7% attainment, both the "below 99.9%" and the "below 99.0%" tiers match. The usual reading is that the highest matching tier wins, so the credit is 25%, not 35%. Say so in the contract. Two related terms are worth writing down at the same time:

• A cap. Most contracts cap the total credit at a share of the monthly fee.
• Multiple services. If the contract covers an API and a dashboard, decide whether the credit is the worst single service (the maximum across lines) or the sum across services, capped.

Missing data is not downtime

Monitoring fails too. Suppose your checks could not reach the service for three hours in a 30-day month and you have no data for that time. There are three ways to treat those 180 minutes:

• Count them as downtime. Attainment drops to 99.5833% and you owe a credit for an outage that may not have happened.
• Count them as available. You may be hiding a real outage from the customer.
• Exclude them and disclose coverage. The 180 minutes leave the calculation, and the statement says the month had 99.58% coverage.

The third option is the most defensible, with one guard: set a minimum coverage (95% is a common choice) below which no credit is calculated automatically and a person reviews the month instead. Otherwise a broken monitor can turn into a 100% credit, or a silent one into a clean record.

Which month, in which time zone

A calendar month starts at midnight somewhere. An outage from 23:30 UTC on 31 March to 00:40 UTC on 1 April is split across two months if the contract uses UTC: 30 minutes in March and 40 in April. For a customer whose contract runs on New York time, all 70 minutes fall on the evening of 31 March. Put the time zone in the contract, and use the same one for every number on the statement.

Making credits verifiable

A credit is easier to agree on when both sides can check the same evidence:

• Freeze the evidence when the period closes. Raw monitoring data often expires after a few months, and credit claims can arrive later. Keep the counts, the exclusions with their reasons and the coverage alongside the statement.
• Publish the method. Downtime definition, exclusions, missing-data rule, rounding and time zone, written once and referenced by every statement.
• Show the working. Per-service attainment, the minutes excluded and why, the tier that applied and the calculated credit.
• Review before sending. A second look catches a misconfigured check before it becomes a contractual statement.
• Make it tamper-evident. A hash and signature let the customer confirm months later that the statement they hold is the one you issued.

A checklist for the contract

• Target and period: calendar month or quarter, and the time zone.
• What counts as downtime for each service, including whether degraded counts.
• The measurement source and how often it samples.
• Maintenance: scheduled or actual window, notice required, and how overruns count.
• Missing data: excluded, down or up, and the minimum coverage for an automatic credit.
• Tiers that apply strictly below the threshold, with the highest tier winning.
• A cap, and how several services combine.
• The claim process: how long the customer has to claim, and whether credits come off future invoices or are refunded.
• How long evidence is kept, and how the customer can verify a statement.

How Observer handles it

Observer's SLA Ledger turns each of these choices into a setting on a per-customer contract: target per service, calendar month or quarter, time zone, whether degraded counts, scheduled or actual maintenance, the missing-data rule with a minimum coverage, credit tiers, a cap and how services combine. Tiers apply strictly below the threshold and the highest one wins. When coverage is too low, the month is flagged for review instead of credited automatically.

Each month the Ledger drafts a statement with the working shown and, by default, holds it for approval before anything is sent. Each statement carries a SHA-256 hash and an Ed25519 signature, and customers can check it on your Reliability Center against Observer's published signing keys. The numbers come from the same metrics that drive your status page and your SLOs, so the page, the error budget and the statement are all computed from the same measurements.

Keep reading

• DORA for SaaS vendors: what your financial customers will ask for
• Incident update templates, and how often to post them
• Why status pages lie
• Status pages: a complete guide