Skip to main content

SLA Reports

Every monitor can produce a self-contained SLA report on demand — a dated document you can attach to a client review, a postmortem, or a compliance folder. No scheduling and no setup: pick a period, pick a format, download.

Where to find it

The Download report button lives on the monitor page — first in the header row of actions, ahead of Edit / Check Now / Pause.

It opens a dialog where you choose a period (Last 24 hours / 7 days / 30 days), optionally an SLA target (99%, 99.5% or 99.9%), and a format (PDF or CSV), then press Download. The period is filled in for you — it is the time range the page is currently showing.

Unlike its neighbours in that row, the button needs no write access: a member with the Viewer role sees it and nothing else.

What’s in the report

Each report is generated from the same data the monitor page shows, so the numbers can’t drift:

99.98%MTTRMTBFP50P90P95P99SLO
  • Availability — uptime percentage and “nines” rating (no more nines than the check interval can tell apart), total / successful / failed checks
  • Reliability (ITIL) — MTTR (mean time to recovery), MTBF (mean time between failures), incident counts, total downtime and partial-outage time. Incidents are the confirmed outages listed on the Incidents page; a failure too short to confirm adds to downtime but is not an incident
  • Latency — P50 / P90 / P95 / P99, plus average, min, and max
  • Error budget — when an SLA target is chosen in the dialog: allowed vs. consumed downtime and the remaining budget. A partial outage burns the budget at half, as it counts in the uptime percentage
  • Incident history — start, duration, and the failure reason for each incident in the period
  • Maintenance — time spent in announced maintenance windows is excluded from uptime, the industry-standard way

What counts against uptime

Availability and health are two different questions, and only the first one moves the percentage.

UP1DEGRADED1PARTIAL0.5DOWN / TIMEOUT0

A degraded check does not reduce uptime. A certificate expiring in three weeks, a domain whose WHOIS expiry we could not read, or a site answering HTTP 429 is still serving — the warning belongs on the monitor, not in the availability number. This is how status pages have always scored it: Atlassian Statuspage and openstatus both give “degraded performance” a downtime weight of zero, and AWS counts only server errors against its own SLA.

A partial outage — reachable from some probe locations and provably not from others — counts as half. Only a full outage or a timeout counts in full.

That is why a report can show 100% uptime next to a non-zero failed-checks count: the degradations are still reported, they just do not deduct from availability.

Cameras

An RTSP camera’s report has a Camera Video section. It shows what the camera’s uptime is made of.

  • Video Degraded — how long the video had gaps, stalls, packet loss or fell below the quality limits, or the camera was busy. The camera still answered, so uptime credits this time; this row shows that the picture was poor.
  • Login Rejected — how long the camera refused the saved login or password. The camera is alive, but the video cannot be checked.
  • Stream Changed — how long the codec or resolution differed from the expected.
  • Frame Rate, Bitrate, Keyframe Interval, Packet Loss — the median and the worst value over the video checks. Stream — the codec and resolution from the latest video check. Video checks, like the rest of the per-check data, are kept for 14 days.

A camera’s latency is called Camera Response: the time the camera takes to answer the RTSP DESCRIBE request, not the video delay. A camera report has no bot-protection row.

PDF or CSV?

  • PDF — a formatted document for stakeholders: clean tables, ready to share or archive.
  • CSV — the same metrics as raw rows for spreadsheets and data analysis. Values are sanitized against spreadsheet formula injection.

The downloaded file is named sla_report_<monitor>_<date>.pdf (or .csv).

Periods and data retention

Reports cover the last 24 hours, 7 days, or 30 days. Uptime, check counts, downtime and incidents cover the whole period. Per-check data is kept for 14 days, so a 30-day report takes latency and the bot-protection count from the last 14 days and says so in its “Measured Over” row.

When the monitor was created or paused inside the period, the report adds a “Monitored Time” row: how much of the period the monitor was actually checked. MTBF and the error budget are computed over that time.

%P9530d7d24h
  • Status page SLA reports — a public, account-free 90-day PDF that visitors of a status page can download themselves.
  • Scheduled reports deliver the same SLA metrics to your inbox on a daily, weekly, or monthly cadence — use them when you want the report to arrive automatically instead of downloading it on demand.