An SLA report answers a sharper question than a plain availability report: not just "how much uptime did this have," but "did it meet the target we committed to."
Setting an SLA target
Before an SLA report means anything, a target needs to be defined for the host, service, or group it applies to — commonly expressed as a percentage (99.9%, 99.95%, and so on) over a set period, typically monthly. Different systems can reasonably have different targets: a customer-facing production service usually carries a stricter target than an internal utility host.
What's in an SLA report
- The defined target alongside the actual measured availability for the period
- Whether the target was met or breached, at a glance
- A list of the specific downtime events that contributed to any breach
- The remaining downtime "budget" for the current period, if it hasn't ended yet — the figure Predictive SLA Breach builds on to warn you before a target is actually missed
Reading a breach
A breached SLA is rarely a single cause — reviewing the underlying downtime events (cross-referencing Alert History for the same period) usually shows whether it was one significant outage, or several smaller ones that added up. That distinction changes what's worth fixing: a single root cause is a different conversation than infrastructure that's chronically a little unreliable.
Why this matters beyond compliance
Even without a formal contractual SLA in place, setting internal targets and tracking them the same way gives a team an honest, consistent measure of reliability over time — one that doesn't depend on remembering how bad a given month "felt."