SLA monitoring: how to measure and prove uptime against an SLA
SLA monitoring is the practice of independently checking a service's availability so you have timestamped evidence of whether it met the uptime percentage a service level agreement promises. That evidence matters most in a dispute, since a provider's own dashboard is not a neutral witness to its own downtime.
What is SLA monitoring?
An SLA (service level agreement) is a contract that names a specific availability target, usually a monthly uptime percentage such as 99.9%, and states what happens if the provider misses it: typically a service credit, sometimes a right to cancel. SLA monitoring is the ongoing measurement work underneath that contract: checking the promised endpoint from outside the provider's own network, logging every outage with a timestamp, and rolling the result up into the percentage the contract cares about. Without that independent record, whether an SLA was met comes down to whose numbers you trust.
Both sides have a reason to run it. A customer wants proof before filing a credit claim. A provider wants an honest number of its own before a customer's monitoring catches a problem first.
SLA vs SLO vs SLI
The three terms get used loosely, but they describe three different things, in order: measure, target, promise.
| Term | What it is | Example |
|---|---|---|
| SLI (Service Level Indicator) | The actual measurement, a number calculated from real checks | Uptime measured from external checkpoints over the last 30 days |
| SLO (Service Level Objective) | An internal target for that indicator, with no contractual consequence attached | "We aim for 99.95% uptime this quarter" |
| SLA (Service Level Agreement) | A contractual promise built on one or more SLOs, with a stated consequence if missed | "99.9% monthly uptime, or a prorated service credit" |
The practical test: if missing the number has no consequence written down anywhere, it is an SLO, not an SLA.
What an uptime SLA actually allows
Every tenth of a percent matters more than it looks like it should. Here is what each common SLA tier allows before it is breached, for a continuous 30-day month and a 365-day year:
| SLA target | Allowed downtime per 30-day month | Allowed downtime per year |
|---|---|---|
| 99% | 7 h 12 min | 3 days 15 h 36 min |
| 99.5% | 3 h 36 min | 1 day 19 h 48 min |
| 99.9% | 43 min 12 sec | 8 h 45 min 36 sec |
| 99.95% | 21 min 36 sec | 4 h 22 min 48 sec |
| 99.99% | ~4 min 19 sec | ~52 min 34 sec |
The jump from 99.9% to 99.99% cuts the allowed downtime by 90%, from about 43 minutes a month to about 4 minutes. See how to calculate uptime for the underlying formula and the reasoning behind each tier.
What to measure so the number holds up in a dispute
- Check from outside the provider's network, and from more than one location. A check that starts and ends on the infrastructure it is testing cannot see a network-level outage that isolates that infrastructure from the internet.
- Match the check interval to the SLA tier. A 5-minute interval cannot reliably prove or disprove a 99.99% target, because the entire monthly allowance is smaller than one check cycle.
- Require confirmation from a second location before counting downtime. One location's own network blip is not the provider's outage; an incident that only opens once several locations agree keeps that noise out of the number.
- Exclude only the maintenance windows the SLA actually documents. Undisclosed maintenance still counts as downtime; a window both sides agreed to in advance does not.
- Measure the exact endpoint the contract names, not a health-check path that answers 200 regardless of whether the real service works.
- Apply the SLA's response-time threshold, if it has one. Some agreements define "down" as slower than a stated response time, not only as unreachable.
- Keep the raw check log, not only the rolled-up percentage. A dispute needs timestamps, response codes and durations, not a single number pulled from a spreadsheet.
How to set up SLA monitoring step by step
- Write down the exact endpoint, the metric (uptime, response time, or both) and the measurement window the SLA specifies. A check against the wrong URL or the wrong time zone produces a number nobody can use.
- Set the check interval short enough for the tier you are proving. As a rule of thumb, keep it well under the smallest outage the target allows, so a 99.9% target needs an interval measured in minutes, not tens of minutes.
- Run the checks from several independent locations outside the provider's own infrastructure, spread across regions where it matters. HostTracker checks from 300+ checkpoints in 158 cities, so you can pick locations close to where your real users sit.
- Turn on a recheck or confirmation rule so one location's failure has to be confirmed by others before it counts as downtime.
- If the SLA sets a response-time threshold, configure it as a failing condition, not just a slow-but-passing result.
- Add the maintenance windows both sides agreed on to the monitoring configuration, so they are excluded from the uptime figure automatically instead of by hand at report time.
- Schedule a recurring uptime report on the same cadence the SLA is measured against, weekly or monthly, so the number is never assembled for the first time during a dispute.
How to report on an SLA
A scheduled report closes the loop between measuring and proving. A weekly or monthly uptime report, sent automatically to whoever owns the relationship on both sides, turns the raw check log into the number the SLA is written against before anyone has to ask for it. A public status page does the same job for anyone outside that distribution list: a shared, time-stamped record of uptime and incidents that neither side has to take the other's word for. See what a status page actually shows if you have not set one up yet. Once you have a period's worth of check results, running them through an uptime calculator gives you the percentage without doing the arithmetic by hand.
Common mistakes
- Measuring from inside your own network. A check that starts and ends on infrastructure you control cannot see an outage that only affects how the outside world reaches you.
- Averaging uptime across several services or regions. A single blended number can hide one service that broke its SLA while others padded the average back up.
- Counting only complete outages. If the SLA has a response-time clause, a service that answers but is far slower than the threshold is in breach too, even though it never went fully down.
- Running a 5-minute check interval against a 99.99% target. The math does not work: 99.99% allows about 4 minutes of downtime a month, less than one check cycle, so the interval cannot resolve whether the target was met.
Frequently asked questions
How is SLA uptime calculated?
The same way any uptime percentage is calculated: (total time minus downtime) divided by total time, multiplied by 100. The SLA-specific part is which downtime counts: only outages against the exact endpoint and window the contract names, with agreed maintenance excluded. See how to calculate uptime for the full formula and worked examples.
Does maintenance count against an SLA?
Only if it was not agreed on in advance. Most SLAs exclude scheduled maintenance that both sides documented ahead of time, but downtime from an unannounced change, or an emergency fix labeled "maintenance" after the fact, still counts. The exclusion is for the disclosed window, not for the word itself.
What is a good uptime SLA?
99.9% is a common baseline for a commercial service, allowing about 43 minutes of downtime a month. 99.95% is a reasonable mid-tier commitment, and 99.99% is a serious commitment that leaves only a few minutes a month, hard to hit without redundant infrastructure and disciplined maintenance. Treat any promise of 100% as a marketing claim rather than an engineering one; the table above shows why.
How do I claim SLA credits?
The general shape is similar across providers: gather your own monitoring evidence for the affected period (timestamps, the endpoint checked, the confirmed downtime), compare it against the provider's own status page or incident record, and submit a claim through the provider's support channel within the window their contract sets, often a set number of days after the incident. Check the specific provider's own SLA document for its exact deadline and required evidence, since these details vary and can expire quickly.
Can one monitoring location prove SLA compliance on its own?
Not reliably. A single location cannot tell a real outage apart from a problem in its own network path to the provider, which is exactly the kind of false positive an SLA dispute cannot survive. Confirmation from more than one independent location before counting an outage is what makes the resulting number defensible.