On this page
The number at the top of an SLA report is a claim: 99.95%, this quarter, on the record. A customer, procurement reviewer, auditor, or regulator may ask a harder question: how do you know? Their required evidence and conclusion depend on their scope.
That question matters in regulated work. DORA has applied since 17 January 2025, and NIS2 sets incident-reporting duties for entities within its scope.
Whether either framework applies, how an incident is classified, and which deadline runs are legal and operational decisions. Those decisions sit outside a monitoring tool. Reviewers still need evidence they can test.
Three gaps are useful checks, and here is how to find them in your own report. These are review questions, not a prediction of an audit outcome.
Work backward from the percentage
Ask three questions of the percentage:
- Which windows counted as downtime?
- Which windows were excluded, and why?
- What recorded the timestamps?
A report that cannot answer those three questions is harder to recompute. That is the bounded test used here, and it assumes no universal auditor behavior.
Rounded windows are the first gap
Many reports tidy outages into round numbers. A window becomes “about 15 minutes,” or anything under 10 minutes is dropped as noise.
The result reads cleanly, but it cannot be reconstructed. An auditor cannot recompute a percentage from a window that has been smoothed.
The stakes are arithmetic. A 99.95% target over a 91-day quarter leaves about 65 minutes of downtime budget across 131,040 minutes. A single window rounded the wrong way can hide a real breach or invent one.
If a 7-minute, 12-second incident is logged as “roughly 15 minutes,” you have overstated your own downtime by almost 8 minutes for no reason. Round it down to zero, and you have quietly erased evidence that a regulator may later reconcile against a customer complaint.
How to close it. Record the real boundaries to the second, and let the percentage follow from them. A window rounded to 15 minutes looks no better, and it cannot be defended.
Silent exclusions are the second gap
Keep two paths distinct. Announced maintenance has a schedule and an announcement before the window. False-positive curation happens after measurement and needs its own actor, reason, before/after effect, and reversal.
Neither path decides what a contract or reviewer must accept.
How to close it. Show the real boundaries and provenance for each path. Label announced maintenance as planned, and label a later correction as curation. Do not present one as the other, and do not silently remove either from the reviewable record.
Self-reported measurement is the third gap
This is the gap teams least expect, because it concerns the vantage point, not the math.
If your availability data comes from a single probe, or worse from the same infrastructure that failed, an auditor has a fair objection. You cannot tell your own network problem apart from a real service outage. A person assembling the timeline afterward also cannot prove that the timestamps were not adjusted to fit.
How to close it. Measure from outside the monitored system. Record observations from more than one plan-selected path before counting an incident.
Agreement across locations is correlated evidence from multiple paths. It reduces dependence on one route but does not prove root cause or legal origin.
Let the monitoring system timestamp events as they happen. Document the policy that turned those observations into an incident.
A report that holds up has three properties
The three properties are unglamorous:
- real window boundaries
- maintenance and curation paths that are visible and distinctly labeled
- measurement taken from outside the system and confirmed across regions
None of this makes your uptime higher. It makes your uptime checkable and gives a reviewer a basis they can verify. A flattering number you cannot defend is worth less than an honest one you can.
Read one line of the sample report
A record is clearer to see than to describe, so Perstat publishes an editorial example. The sample SLA report illustrates a single quarter for a demo service, and every number in it adds up. It is not an automatically generated customer report.
A check fails in Frankfurt at 02:40:42 UTC, but the incident does not open there. Thirty seconds later, probes in Newark and Singapore agree the service is unreachable. Quorum confirms, and the incident opens at 02:41:12 UTC. The sample monitor runs a policy of 1 failed check per region with a quorum of 2 regions, not the default of 2 consecutive checks.
That confirmation is the start of the counted window, 02:41:12 to 02:48:24 UTC. The window does not start at the first failed check or at a rounded minute.
The 90-minute maintenance window later that month is excluded, but it stays on the report with its announcement timestamp. Gross availability is 99.925%. After excluding that announced maintenance, it is 99.994%.
The editorial arithmetic is recomputable. The sample is not an assurance report or a regulatory filing.
Classification and filing stay with your team
A monitoring product does not establish compliance with DORA or NIS2 for anyone. Classification, filing, and deadlines stay your responsibility. A tool can contribute system timestamps, measurements, maintenance records, and visible curation to the broader evidence your team assembles.
If your current report cannot answer the three questions above, that is worth knowing now. At this point, the only cost is a slightly less flattering number.
You can start monitoring free or walk through the product first. You do not need a sales call to see how the record is kept.