SLA reporting

Define an SLA

An SLA is a named target over a set of monitors. Open SLAs → New SLA as an editor or admin. Viewers and read-scope API keys can read SLAs and export reports but cannot create, change or issue them. The API requires migration 000090.

How availability is measured

Every number comes from the monitors' state history (the timeline behind the monitor detail headline), never from counting check results. For each monitor, time in the period falls into exactly one class. Available: up, suspect, or degraded unless the SLA counts it as down. Unplanned down: down outside every maintenance window that covers the monitor, directly or through one of its groups. Planned down: down inside such a window. Paused. Unknown: no fresh evidence. Untracked: no state history yet. A monitor is down for whatever failed its checks, its own assertions included: a SIP test call failing a call-quality threshold counts as downtime like one that was not answered, and its warnings never do.

Availability = available ÷ (available + unplanned down). Planned downtime, paused, unknown and untracked time leave the denominator. Coverage (available plus all down time, ÷ the period) reports how much of the period was actually observed; read a high availability with low coverage accordingly. Overlapping maintenance windows are merged before they are subtracted, so shared time counts once.

Serial (default)

The service is down whenever any member is in unplanned downtime; excluded whenever no member is down but one is planned-down, paused, unknown or untracked; otherwise available. This is how most contracts are worded, and it is the stricter mode.

Mean

The unweighted average of each member's own availability, the same convention the dashboard uses for scopes. The error budget is derived from that average, so budget left ≥ 0 exactly when the target is met.

Reports

The SLA page opens on the running period, reported to date. Step back through earlier periods, or pick a custom range of whole local days (up to 400). A report shows availability against the target and a met/breached verdict, coverage, and the error budget: the downtime the target allows so far (1 − target × eligible time), how much of it was consumed, and the allowance for the full calendar period.

• Daily availability in the SLA's timezone, coloured at or above target / below target but ≥ 99% / below 99% / no data.
• A per-monitor table with availability, coverage, unplanned and planned downtime, paused time and outage count.
• Service outages (serial SLAs): the spans during which the composite was down, maintenance excluded.
• Monitor outages: each monitor's merged down spans with their planned share. Clipped spans are marked as starting earlier or ongoing. The list shows the first 500; counts and exports cover all.
• Response: outage count, mean time to recover (outages wholly inside the period with unplanned time), availability alerts triggered in the period, and mean time to acknowledge.
• Suspected causes: monitor outages bucketed by the triage of their overlapping availability alerts, into named suspected causes, inconclusive, triage pending, not triaged and no alert (see Suspected causes). Columns: cause (marked * when it includes operator-labelled outages), outages, downtime, share of the attributed downtime, monitors, and the operator-confirmed and operator-corrected counts, with a note that these are observed symptoms, not confirmed root causes. Counts are monitor outages, not alerts, and the monitor-outage list gains a suspected-cause column. Like the PDF table, the panel and the column appear only when at least one monitor outage was triaged (suspected or inconclusive), so a workspace without auto-triage sees neither. Reports issued before this breakdown existed have none.

Export any report as PDF (an A4 document with the headline, budget, daily strip, monitor table, suspected causes, outages and method note), CSV (summary, daily, monitor, outage and suspected-cause sections separated by blank lines, times in the SLA's timezone) or JSON (the full report document). The PDF's suspected-cause table appears under the same rule as the page's panel, only when at least one monitor outage was triaged (suspected or inconclusive), so a workspace without auto-triage never sends a table of "Not triaged". The CSV is the raw-data export, so its shape does not depend on AI settings: every report computed since the breakdown existed, AI on or off, gains Cause key and Suspected cause columns on its outage rows and a trailing suspected-cause section (attributed, triaged and pending outage counts, summed unplanned seconds, then one row per bucket), with Not triaged or No alert where nothing was triaged. Reports issued before the breakdown existed export exactly as they did. The monitor detail page uses the strictest target of the SLAs covering that monitor, falling back to 99.9%.

Suspected causes

With automatic alert triage on, Probara's local AI names a suspected cause for each new alert. SLA reports roll the period's monitor outages up by those causes, so a report says what kind of failure consumed the error budget as well as how much.

• Each per-monitor outage with unplanned time takes the effective cause of the availability alerts on its own monitor that overlap it, with 2 minutes of slack for an alert that triggered just after a short outage closed. When several alerts overlap, a named cause wins over an inconclusive triage, which wins over a pending one, which wins over none. The whole outage's unplanned time goes to that one cause.
• The model's hypothesis counts as a suspected cause only when the triage rated it medium or high confidence, the same bar as the suspected-cause follow-up; a low-confidence hypothesis is inconclusive. An operator's label on the triage (confirm or correct) wins over the model's hypothesis, whatever its confidence. The breakdown counts how many outages per cause were operator-confirmed or operator-corrected, and the PDF marks such causes with an asterisk.
• Counts are monitor outages, not alerts. Downtime is summed per monitor, so when monitors fail together it can exceed the service's downtime.
• Composite (service) outages, group roll-up alerts and incident analyses are not attributed.

Issued reports

A live report of a past period is recomputed on every view, so it changes when someone edits or deletes a maintenance window, wipes a monitor's history, or changes the SLA itself, and as triages complete and operators label or relabel alerts (which moves outages between suspected-cause buckets). Issue a report to freeze a closed period. Probara stores the complete report, including the SLA settings and resolved monitor list at that moment, and every later download of it renders from that snapshot. That includes each suspected cause's bucket and title, whatever the catalogue later calls the key; outages still pending when it was issued stay pending. Only closed calendar periods can be issued, once each. Deleting the SLA deletes its issued reports; purging a monitor does not.

API

The report document carries suspected_causes (outage_count, triaged_outage_count, pending_outage_count, unplanned_seconds, and buckets with kind, key, title, outage_count, alert_count, monitor_count, unplanned_seconds, confirmed_outage_count, corrected_outage_count), and each attributed monitor outage carries cause_kind, cause_key and cause_title. key is the catalogue key for suspected causes and the bucket kind otherwise. All of these are absent on reports issued before the breakdown existed; treat them as optional.