An uptime SLA report is a dated document stating measured availability against the committed target for one defined period, and a complete one contains nine things: the service covered, the period, the committed target, the measured availability, total counted downtime, every incident with start and end times, excluded maintenance, the measurement method, and any service credit owed. Leave out the measurement method and the report is not auditable, because the reader has no way to know whether your 99.94% and their 99.81% describe the same month.
Most teams produce their first one under pressure, usually because an enterprise customer asked for it during a renewal or a security review. Assembled in a hurry from dashboard screenshots, it tends to raise more questions than it settles. Below is what belongs in one, a worked example with real arithmetic, and the measurement decisions that quietly change the number.
Who actually asks for an uptime SLA report
Three groups, and they want different things from the same document. Enterprise customers with an availability clause want proof you met it and a credit if you did not. Auditors working through SOC 2 or ISO 27001 want evidence that availability is monitored continuously and that incidents are recorded, and they care more about the process being consistent than about the number being high. Your own leadership wants the trend.
A single report can serve all three if it is honest and dated. It cannot if it is a screenshot, because a screenshot has no defined period and no stated method.
What to include in an uptime SLA report
Nine elements. The first five are the ones every template has. The last four are the ones that survive a dispute.
- Service and scope. Which endpoints or components this figure covers. "The application" is not scope; the login endpoint, the public API and the customer dashboard are.
- Reporting period. Exact start and end, with the timezone. Calendar months and rolling 30-day windows produce different numbers and contracts disagree on which applies.
- Committed target. The percentage from the contract, stated as written.
- Measured availability. The result, to two decimal places. More precision than that is false confidence given the check interval.
- Total counted downtime. In minutes and seconds, not just as a percentage. This is the number people check your arithmetic against.
- Incident log. Every incident with start time, end time, duration and a one line cause. Omitting a short incident to improve the number is the fastest way to lose the argument when the customer's own monitoring saw it.
- Excluded time. Scheduled maintenance and any contractual exclusions, listed individually with the notice you gave. Exclusions applied without being shown look like accounting.
- Measurement method. Check interval, the locations you checked from, what counted as a failure, and how many consecutive failures were required before downtime started.
- Credit position. Whether the target was met, and if not, the credit tier that applies and how to claim it.
A worked monthly example
Take June, a real 30-day month of 43,200 minutes, and a 99.9% commitment. That target allows 43 minutes 12 seconds of downtime in that specific month. (Generic reference tables usually quote 43 minutes 50 seconds for 99.9%, because they assume an average month of 30.44 days. Report against the month you actually measured, and say which you used.) Three incidents happened.
| Incident | Start (UTC) | End (UTC) | Duration | Counted? |
|---|---|---|---|---|
| Database failover | Jun 4, 02:14 | Jun 4, 02:31 | 17 min | Yes |
| Upstream DNS provider outage | Jun 12, 15:02 | Jun 12, 15:11 | 9 min | Yes |
| Scheduled database upgrade (14 days notice) | Jun 22, 03:00 | Jun 22, 03:40 | 40 min | No, excluded maintenance |
| Deploy rollback | Jun 27, 11:48 | Jun 27, 11:54 | 6 min | Yes |
Counted downtime is 17 + 9 + 6 = 32 minutes. Availability is (43,200 minus 32) divided by 43,200, times 100, which is 99.93%. The target was 99.9%, so the month passed with 11 minutes 12 seconds of budget left. The report says exactly that, including the excluded 40 minutes, because hiding the maintenance window is what makes a customer stop trusting the rest of the document.
Notice what nearly went wrong. Had the maintenance not been excludable under the contract, counted downtime would have been 72 minutes, availability 99.83%, and the month a breach. Whether your contract permits that exclusion, and whether you gave the required notice, is worth more than any monitoring feature.
Why two tools report different uptime for the same service
This is the most common reason an SLA report gets challenged, and it is rarely anyone lying. Three measurement choices move the number.
Check interval sets the resolution. A monitor only sees the service when it looks, so the shortest outage it can record is one missed check. At five-minute checks, a 90-second outage is either invisible or recorded as five minutes, depending on timing. At 30-second checks the same outage records as roughly 90 seconds. Neither is wrong; they have different resolution. This is also why a 99.99% target cannot be evidenced with five-minute checks at all: the whole monthly allowance is 4 minutes 19 seconds, which is less than one check interval.
Confirmation policy decides what counts. A tool that records downtime on the first failed request from one location will count transient network blips as outages. A tool that requires two or three regions to agree before recording downtime will not. The second approach reports higher availability, and it is the more defensible one, because a route flapping between one datacenter and your load balancer is not your service being down.
Check depth decides what "up" means. A check that accepts any HTTP 200 will report a healthy month for an application that spent a week returning an empty product list. If your customer's definition of available is "the feature worked", assert on something in the response body that only exists when the request genuinely succeeded. We go into this in synthetic monitoring vs uptime monitoring.
State all three in the method section. A report that says "checked every 30 seconds from US East and EU Central, downtime recorded only when both regions failed consecutively" is one a customer can reconcile against their own data. A report that says "99.93%" is one they have to take on faith.
What the report should say when you missed the target
Send it anyway, on the same schedule, in the same format. A missed month reported on time reads as a functioning process; the same miss reported after the customer chases it reads as concealment.
Include the credit position explicitly, even though in almost every contract the credit is something the customer must claim rather than something you pay automatically. Naming the tier that applies costs you nothing you did not already owe and it removes the suspicion that you were hoping the deadline would pass. The tiers, the caps and the claim windows are covered in SLA service credits.
Then add one paragraph on what changed. Not a postmortem, just the concrete remediation and its date. A customer deciding whether to renew is really asking whether next quarter looks like last quarter.
How often to send it, and how to stop doing it by hand
Monthly is the norm and matches how most availability clauses are written. Quarterly is enough for internal targets with no contractual teeth. Weekly reporting tends to produce noise, because a single 20-minute incident in a 7-day window reads as 99.80% and triggers a conversation that a monthly view would have absorbed.
Doing it by hand is fine for one customer and untenable at ten. Two ways out. The first is a monitoring tool that generates the report itself, which several do: Uptime.com, Site24x7, Dotcom-Monitor and AlertSite all document a named SLA report, and AlertPing produces them on the Business plan. The trade-offs are laid out in our comparison of SLA monitoring software.
The second is to export the raw check results and build the report where the rest of your reporting already lives. That is more work up front and much more flexible, particularly when the contract defines downtime in a way no vendor's default calculation matches. If the check history is already sitting in your warehouse, you can ask for the month's availability in plain English rather than maintaining another SQL view, and keep the contractual exclusions as data rather than as a manual adjustment somebody remembers to apply.
A shortcut that removes most of the requests
Publish rolling uptime on a public status page. A page showing the last 90 days of availability per component answers the routine version of the question before anyone asks it, and it turns the monthly report into a formality rather than a negotiation. It also means the number your customer quotes is the number you published, continuously, rather than one you assembled after the fact.
You still need the formal report for the contract and the auditor. But the volume of "can you send us last month's uptime" emails drops close to zero, and the SLA conversation starts from shared data. If you do not have one yet, how to create a status page walks through it, and the underlying number is the same one covered in how to calculate uptime percentage.