SLA Service Credits: "99.9% Uptime" Means Different Things Depending on What You Divide By
An SLA that promises "99.9% uptime" reads like a single, unambiguous number. It isn't, until three questions are answered: 99.9% of what hours, over what period, and what happens when an outage straddles the boundary of that period. Vendors and customers who never nail down those three questions can both run the same downtime incident through their own math and arrive at different verdicts on whether the SLA was breached — and different numbers for the service credit owed.
Business hours vs. every hour of the day
The most consequential fork is the denominator. Some SLAs measure uptime against every hour in the period — 24 hours a day, seven days a week — because the service is expected to be available at all times. Others measure only against the customer's business hours, on the theory that downtime at 3am on a Sunday doesn't cost the customer anything if nobody was using the service anyway. These are genuinely different promises: a service with frequent short outages that always land overnight could show a poor 24/7 uptime number while showing a nearly perfect business-hours number. Before you compute — or dispute — an uptime percentage, confirm which denominator the actual SLA document specifies. Applying a business-hours calculation to a contract that promises 24/7 uptime understates the real breach.
The measurement period is usually a calendar month, not a rolling window
Most SLA credit clauses measure uptime over a calendar month — the one containing the incident, not a rolling 30-day window ending whenever you happen to run the numbers. That matters because an outage starting on the 30th and continuing into the next month splits across two separate measurement periods, and each period's percentage is computed independently against its own business-hours total. Downtime doesn't merge across the boundary; it has to be evaluated month by month, incident portion by incident portion.
Working hours and the workweek pattern also define the denominator, and they need to match what's actually staffed, not what a website footer claims. A team with a 9am–5pm, Monday–Friday window has a smaller pool of business hours in a given month than one covering 8am–8pm six days a week — and the same outage duration produces a much larger percentage hit against the smaller pool. Public holidays subtract further business hours from the denominator, so a month with a national holiday has fewer total business hours to divide by than a month without one, all else equal.
What "missed" actually triggers
An SLA breach isn't just "there was an outage" — it's uptime for the whole measurement period falling below the contractual target. A single long outage in an otherwise perfect month can absolutely drag the period below target; a handful of short outages might not, if the total downtime stays under the allowed threshold implied by the target percentage. Knowing the exact allowed-downtime figure for your target — not just the percentage — makes it obvious how much headroom is left before the next incident tips the month into breach.
Service credits are usually a flat percentage of the affected period's fee
Where a breach did occur, the remedy in most SLAs is a service credit — a percentage of that billing period's fee, not the whole contract value, and typically flat rather than scaled to how badly the target was missed. A month that missed 99.9% by one hour and a month that missed it by ten hours can trigger the identical flat credit under a simple SLA, though many enterprise contracts do tier credits by severity of breach — check whether yours is one of them, since a flat-rate clause and a tiered clause produce very different numbers for a bad month.
Run the actual numbers, not the gut estimate
The SaaS SLA Service Credit Calculator takes the outage start and end timestamps, your SLA target, and your working hours and workweek, and computes business-hours downtime against the total business hours in that calendar month — along with the allowed downtime at your target and an estimated service credit if the month missed. If the outage spans past the end of the month, the tool flags that explicitly so you know to run the remainder against the following month separately.
This tool computes uptime against business hours in the calendar month the outage started in, using a flat service-credit percentage — confirm both conventions against your actual SLA document, since 24/7 measurement, rolling windows, and tiered credit schedules are all common variations this calculation does not assume.