sla uptime monitoring
SLA monitoring for uptime: track, measure and prove your uptime SLA
Short answer: SLA monitoring is measuring a service's real availability against the uptime promise in a service level agreement, so you can prove you met it or catch a breach the moment it starts. It works by checking the service from outside on a fixed interval, recording every failure, and reporting the availability percentage over a defined window. The tighter the SLA, the shorter the check interval has to be: a 99.99% SLA allows only 4 minutes and 23 seconds of downtime a month, so a 5-minute check can miss the entire breach. AlertPing checks every 30 seconds from three regions and turns that data into a live SLA number and a public status page.
Last updated July 2026 · 30-second checks from three regions
alertping ▸ run check
live
▸ type a domain and run a real-feel check
▸ probes from 3 regions · FRA · IAD · SIN
▸ waiting…▌
queued probing▌
If ever goes down, you get:
Alert fired ▸ 2 channels · 6.2 s after first failure
AlertPing app
● DOWN : HTTP timeout confirmed from 3/3 regions (FRA, IAD, SIN). Incident opened.
sms · on-call
AlertPing: DOWN. Confirmed 3/3 regions . First fail: Frankfurt.
start here
What SLA monitoring actually measures
An SLA is a contract clause that promises a level of availability, almost always written as a percentage of uptime over a period. SLA monitoring is the measurement that keeps that promise honest. It answers one question with a number: over this window, what fraction of the time was the service actually reachable and working?
Availability, as a formula
Availability is uptime divided by total time in the window, expressed as a percentage. If a service was reachable for 43,195 of 43,200 minutes in a 30-day month, that is 99.988%. The monitor supplies both numbers by testing on a fixed cadence.
A defined window
The percentage is meaningless without a period. Most SLAs measure per calendar month and reset on the first. Some measure per billing cycle or per quarter. The window decides how forgiving the number is, because a fixed budget of downtime spreads across it.
What counts as down
Downtime is not only "the server stopped answering." A page that returns 200 with an error body, an expired certificate, or a response slower than the agreed threshold can all breach an SLA. What counts as down should be written into the agreement, then measured exactly that way.
the numbers
How much downtime each SLA level actually allows
Each extra nine cuts the allowed downtime by a factor of ten, and it shrinks fast. This table is the one every SLA conversation comes back to: what a percentage buys you in real minutes, and how often you have to check to even see a breach of that size.
| Uptime SLA | Downtime / day | Downtime / month | Downtime / year | Check interval it needs |
|---|---|---|---|---|
| 99% (two nines) | 14m 24s | 7h 18m | 3d 15h | 5-minute checks are enough to see it |
| 99.9% (three nines) | 1m 26s | 43m 50s | 8h 46m | 1-minute checks or better |
| 99.95% | 43s | 21m 54s | 4h 23m | 30 to 60 seconds |
| 99.99% (four nines) | 8.6s | 4m 23s | 52m 35s | 30 seconds; a 5-minute check can miss the whole breach |
| 99.999% (five nines) | 0.9s | 26s | 5m 15s | 30 seconds is the floor; the budget is near zero |
The right column is the part most tools skip. If your check interval is longer than the downtime the SLA allows, an outage can begin and end between two checks and never register. That is why a five-minute monitor cannot honestly report on a 99.99% SLA: the entire monthly budget is 4 minutes and 23 seconds. We break the percentages down further in what 99.99% uptime means in real downtime and cover how to pick a target in what is a good uptime percentage.
the method
How to measure an uptime SLA you can defend
A number you can defend in a customer dispute has to come from outside your own network, on a clear interval, with the rules agreed in advance. Five things separate a real SLA measurement from a comforting guess.
Check from outside, from more than one place
A monitor living inside your own infrastructure goes dark at the same moment the service does, so it undercounts the worst outages. An external check sees what a customer sees. Confirming from a second region before recording downtime stops one flaky network hop from adding false minutes to your report and understating your real availability.
Match the interval to the target
Read the SLA math table backwards. The allowed downtime sets the longest check interval that can honestly measure it. For anything at or above 99.9%, a 30-second interval both catches the breach early and gives you the resolution to say how long it really lasted, to the second, not the nearest five minutes.
Define downtime, then measure that
Decide what a breach is before you need to argue about one. Assert on the response body and response time, not just the status code, so a page that loads broken counts as down. The same content and latency assertions used in API monitoring are what make an SLA measurement match the customer's experience.
Handle maintenance windows honestly
Most SLAs exclude scheduled, announced maintenance from the availability calculation. Excluding it is fair; hiding an unplanned outage inside a "maintenance" label is not. Keep the excluded windows explicit and pre-announced so the reported number stays trustworthy to the customer reading it.
alertping
Turn your checks into a live SLA number
AlertPing records every 30-second check from three regions and publishes your rolling uptime percentage on a hosted status page, so the SLA figure is measured, not estimated.
the vocabulary
SLA, SLO and service credits, kept straight
These three words get used interchangeably and mean different things. Monitoring touches all three, because the same measured availability number feeds each one.
| Term | What it is | Where monitoring fits |
|---|---|---|
| SLA | The external promise in the contract, with a consequence attached if you miss it | Supplies the proof you met it, or the timestamped record when you did not |
| SLO | Your internal target, usually set stricter than the SLA to give yourself headroom | Alerts you as you burn the error budget, before the SLA is at risk |
| Service credit | The refund or credit owed to the customer when the SLA is breached | The measured downtime decides who owes what, so the number has to be defensible |
A practical rule: set your internal SLO tighter than the SLA you sell. If you promise customers 99.9%, run your own alerting against 99.95%, so you are reacting to trouble with budget still left rather than after the promise is already broken.
who this is for
Who needs SLA monitoring
SaaS with a signed SLA
If your enterprise contracts promise 99.9% or better, you need an independent record of it. A buyer's procurement team will ask for the number, and a screenshot of your own dashboard is not the same as measured, timestamped history.
Agencies and MSPs
When uptime is part of a care plan you resell, monthly SLA reporting per client is the deliverable. A shared status page and a rolling percentage per site turn that into a product, covered in uptime monitoring for agencies.
API providers
An API SLA is measured on responses, not just reachability. You have to assert the endpoint returns the right payload within the latency you promised, then hold your availability number to that stricter bar.
Ecommerce and payments
A payment or checkout path with an availability commitment needs measurement tight enough to catch a breach that lasts seconds. At 99.99%, the whole month's budget is under five minutes, so the interval has to be short.
why us
Why teams measure their SLA with AlertPing
30-second resolution
AlertPing checks every 30 seconds, so even a 99.99% SLA is measurable and a breach is timed to the second, not rounded to the nearest five minutes.
Three regions confirm
Downtime is only recorded once a second region agrees, so a single bad route does not inflate your outage minutes or understate the availability you actually delivered.
A published status page
Your rolling uptime percentage goes on a hosted status page customers can read, turning the SLA number into something you show, not just claim.
Content and latency checks
Assert on the body and the response time, so a slow or broken-but-200 response counts against the SLA the way your customer experiences it.
The honest limit
External monitoring measures availability from the outside, which is the number that matters for an SLA. It is not a full observability suite: it will not trace a slow query or profile your application internals. If you need request-level tracing and code-level metrics on top of the availability number, pair it with an APM tool. What AlertPing gives you is the defensible uptime figure and the alert, measured the way the contract reads.
sla questions
SLA monitoring questions, answered
What is SLA monitoring?
SLA monitoring is measuring a service's real availability against the uptime level promised in a service level agreement. It checks the service from outside on a fixed interval, records every failure, and reports the availability percentage over a defined window, so you can prove the SLA was met or see a breach as it happens.
How do you calculate an uptime SLA?
Divide uptime by total time in the window and multiply by 100. If a service was up for 43,180 of 43,200 minutes in a 30-day month, that is 99.95%. A monitor supplies both numbers by testing on a fixed cadence, so the availability percentage is measured from real checks rather than estimated.
What is a good uptime SLA?
99.9% is the common commercial baseline and allows about 43 minutes of downtime a month. Critical infrastructure aims for 99.99%, roughly 4 minutes a month. Beyond that, each extra nine costs far more to deliver, so pick the highest level you can actually hold rather than the biggest number you can print.
What does 99.99% uptime mean?
99.99% uptime, or four nines, means the service can be down at most 0.01% of the time: about 8.6 seconds a day, 4 minutes and 23 seconds a month, or roughly 53 minutes a year. Because the monthly budget is so small, you need a check interval of 30 seconds or less to measure it honestly.
How do you measure SLA compliance?
Check the service from outside your network on an interval shorter than the SLA's allowed downtime, confirm each failure from a second region, and total the confirmed outage minutes against the window. Exclude only pre-announced maintenance. The resulting percentage, with timestamps, is your compliance record.
Does maintenance count against an SLA?
Usually not, if it is scheduled and announced in advance under the terms of the agreement. Planned maintenance windows are typically excluded from the availability calculation. Unplanned outages always count, and labeling an unplanned outage as maintenance to protect the number is exactly the kind of thing an independent measurement exists to prevent.
Measure your SLA, do not estimate it
30-second checks from three regions, a rolling uptime percentage, and a status page that shows the number. Running in under a minute, SMS included on every plan.