SLA Monitoring Software and Tools: Track Your Uptime SLA and Prove Compliance
Uptimehub records every second your service is unavailable, converts it into an availability percentage against the target in your contract, and publishes the evidence on a status page your customers can check themselves.
Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
In short
SLA monitoring is the practice of continuously measuring a service against the availability target written into its service level agreement, then keeping a timestamped record of every outage so compliance can be proven or disputed with evidence rather than memory. For an uptime SLA the measured number is availability: total time in the period minus confirmed downtime, divided by total time. A 99.9 percent monthly SLA allows 43 minutes and 12 seconds of downtime in a 30 day month, so a single 50 minute incident breaches it. Uptimehub checks your endpoints every minute from 6 regions, confirms a failure across regions before it counts it as downtime, and turns the result into a monthly availability figure and a public uptime history. That distinguishes it from ITSM tools such as ServiceDesk Plus or PagerDuty, which track SLAs on ticket response and resolution time rather than on whether the service itself was reachable.
What you get
SLA monitoring for developers, SaaS teams and agencies
Downtime measured to the second
Every failed check is timestamped and every incident gets a start, an end, and a duration, so your availability figure traces back to evidence instead of estimates.
Compliance math done for you
Uptimehub converts recorded downtime into a monthly and yearly availability percentage against your target, so you know where you stand before the customer asks.
Evidence customers can check
A branded status page publishes live status and historical uptime, which turns an SLA claim into something a prospect can verify during procurement.
Confirmed across regions first
A failure seen from one region is retried from the others before it counts against your number, so a flaky network path never inflates your recorded downtime.
How it works
From URL to alert in four steps
Set your SLA target
Add the endpoints covered by the agreement and record the availability target you committed to, typically 99.9 or 99.95 percent.
We measure from 6 regions
Uptimehub checks every minute and confirms failures across regions, so recorded downtime reflects real unavailability.
Track the number monthly
Availability, incident count, and downtime minutes roll up per monitor and per period, with the remaining error budget visible.
Publish the proof
Your status page shows current status and uptime history, and alerts reach the team while there is still budget left to protect.
On this page
How much downtime does each uptime SLA allow?
This is the table every SLA conversation comes back to. Availability targets sound interchangeable until you convert them into minutes, and the gap between 99.9 and 99.99 percent is the difference between a long lunch and five minutes a year. Monthly figures below use a 30 day month, which is the convention most SaaS contracts use.
| Uptime SLA | Allowed downtime per day | Per month (30 days) | Per year (365 days) |
|---|---|---|---|
| 99% | 14m 24s | 7h 12m | 3d 15h 36m |
| 99.5% | 7m 12s | 3h 36m | 1d 19h 48m |
| 99.9% (three nines) | 1m 26s | 43m 12s | 8h 45m 36s |
| 99.95% | 43s | 21m 36s | 4h 22m 48s |
| 99.99% (four nines) | 8.6s | 4m 19s | 52m 34s |
| 99.999% (five nines) | 0.9s | 26s | 5m 15s |
Two practical consequences fall out of this. First, at 99.99 percent and above you cannot detect a breach with a five minute check interval, because the entire monthly budget is shorter than one check gap. Measuring a four nines SLA honestly requires checking at least every minute. Second, the period matters as much as the percentage: a 99.9 percent yearly SLA lets you take a single 8 hour outage and still comply, while the same percentage measured monthly caps you at 43 minutes. Read which one your contract says before you promise it.
How to calculate uptime percentage for an SLA
The formula is simple and worth writing down, because arguments about SLA credits are usually arguments about the inputs rather than the arithmetic.
Availability = (total minutes in period minus downtime minutes) divided by total minutes in period, times 100.
A 30 day month contains 43,200 minutes. If your API was confirmed down for 26 minutes across two incidents, availability is (43,200 minus 26) / 43,200 x 100 = 99.94 percent. Against a 99.9 percent target you are inside the budget with 17 minutes to spare. Against a 99.95 percent target you have missed it by half a minute, which is exactly why the third decimal place belongs in the contract.
The number that trips teams up is partial degradation. If checkout was broken for 40 minutes but the marketing site stayed up, availability depends entirely on what the SLA scopes. Scope it per service, monitor each covered service as its own check, and the calculation stops being a judgment call. If you want the plain-English version of the target itself, we walk through what 99.9 percent uptime actually means and what counts as a good uptime percentage in more depth.
What counts as downtime, and who decides
Most SLA disputes are definitional. Before you can monitor an agreement you have to settle five things in writing, and a monitoring tool can only enforce what the contract actually says.
- What is checked. A homepage returning 200 is not proof the API is healthy. Name the endpoints, and monitor each one separately.
- What counts as a failure. A timeout, a 5xx response, a missing keyword on the page, and a slow but successful response are four different conditions. Decide which of them breach the agreement.
- From where. Availability measured from one city is not availability. Multi-region checks with cross-region confirmation stop both false alarms and convenient blind spots.
- How long before it counts. Many contracts only start the clock after a failure persists for a defined confirmation window, commonly two consecutive failed checks.
- What is excluded. Scheduled maintenance announced in advance is usually excluded. Force majeure and customer-caused faults normally are too. Everything else counts.
On who measures, the honest answer is that vendor-run monitoring is the working record and the customer is entitled to check it. That is why publishing uptime history publicly is worth more than a private dashboard: it removes the suspicion that the number was reconstructed after the incident. A status page that has shown the same data continuously for a year is far harder to argue with than a spreadsheet produced during a renewal negotiation. Our guide to what a status page is and why it matters covers how to set that expectation with customers.
SLA, SLO, and SLI: which one are you monitoring?
These three get used interchangeably in meetings and they are not the same thing. Getting them straight is the fastest way to make an availability conversation productive.
| Term | What it is | Who it is for | Example |
|---|---|---|---|
| SLI (indicator) | The raw measurement you take | Engineering | Percentage of HTTP checks returning 200 within 5 seconds |
| SLO (objective) | The internal target for that measurement | Engineering and product | 99.95% of checks succeed each month |
| SLA (agreement) | The contractual promise, with a penalty attached | Customers, legal, sales | 99.9% monthly uptime or the customer receives service credits |
The usual pattern is to set the internal SLO tighter than the external SLA, so the team gets alerted and reacts while there is still contractual room left. If you promise 99.9 percent and target 99.95 percent internally, you have roughly 21 minutes of warning budget before the promise itself is at risk. Uptime monitoring supplies the SLI. The SLO is the line you alert on. The SLA is what you owe. That 21 minute gap is what SRE teams formalize as an error budget, with a burn rate you can alert on before the contract is anywhere near breached.
Who needs uptime SLA monitoring
Four situations make this non-optional rather than nice to have.
You sell a SaaS product with an uptime clause. Enterprise procurement asks for the number, and increasingly asks to see the history behind it. Having twelve months of published uptime shortens security reviews.
You are an agency or MSP on the hook for client sites. Your contract promises availability you do not fully control. Independent external measurement per client, with per-client status pages, is what turns a disputed outage into a documented one. Our monitoring for agencies page covers that setup.
You are the customer holding a vendor to their SLA. Vendors rarely volunteer credits. If your business depends on a payment gateway or a third party API, monitor it yourself and you will have your own record when you claim.
You run internal services with an agreed availability target. Platform teams commit to internal customers too, and the same measurement discipline applies even when no money changes hands.
In every case the requirement is the same: an independent, external, continuously running measurement with a retained history. Uptimehub runs those checks every minute from 6 regions, on flat per-monitor pricing that does not charge extra for the team members who need to read the reports. You can see the covered check types on our uptime monitoring and API monitoring pages, and the reporting surface on the status page feature.
FAQ
Questions buyers ask about SLA monitoring
SLA monitoring is the continuous measurement of a service against the targets written into its service level agreement, most often an availability percentage, so compliance can be proven with a timestamped record instead of recollection. In practice it means running external checks on the covered endpoints, recording every confirmed outage, and rolling that up into a monthly availability figure you can report.
Take the total minutes in the period, subtract the confirmed downtime minutes, divide by the total minutes, and multiply by 100. A 30 day month has 43,200 minutes, so 26 minutes of downtime gives (43,200 minus 26) / 43,200 x 100 = 99.94 percent availability. The hard part is not the formula, it is agreeing what counts as downtime and from where it is measured.
A 99.9 percent uptime SLA means the service may be unavailable for no more than 0.1 percent of the measurement period. Measured monthly on a 30 day month that is 43 minutes and 12 seconds. Measured yearly it is 8 hours 45 minutes, which is a much softer promise, so always check which period your contract specifies before committing to the number.
An SLI is the raw measurement, such as the percentage of checks that succeeded. An SLO is your internal target for that measurement. An SLA is the contractual promise made to a customer, with a penalty such as service credits if you miss it. Teams usually set the SLO tighter than the SLA so they get warning before the contract is at risk.
The vendor normally keeps the working record, but the measurement only settles disputes if the customer can inspect it. Publishing uptime history on a public status page is the practical answer, because continuously published data is far more credible than a report compiled after an incident. Customers with critical dependencies should also run their own external checks.
Most B2B SaaS products commit to 99.9 percent monthly, which allows about 43 minutes of downtime per month and is achievable on a well-run single-region stack. 99.95 percent is common for infrastructure and payment services. Promising 99.99 percent means redundancy across regions and a monthly budget of just over 4 minutes, so only commit to it if the architecture genuinely supports it.
Last updated July 2026
More monitor types
Start monitoring in two minutes
Add a URL or endpoint and Uptimehub checks it every minute from 6 global regions, alerts you in seconds, and updates your branded status page. Read-only checks that never touch your servers.