Metrics & KPIs

Overview

Every check an agent runs produces a raw result: success or failure, timing measurements, and (for some monitor types) protocol-specific data. All dashboard KPIs, charts, and PDF reports are derived from these raw results. This page explains each metric, how it is computed, and what to watch for.

Availability

Uptime (%)

The share of time your service was reachable over a period. Shown for 24h, 7d, 30d, and 365d windows.

uptime = UP time / (total time − maintenance time) × 100

Scheduled maintenance windows are excluded from the denominator — planned downtime never counts against your uptime or SLA.

A monitor is only marked DOWN after 2 consecutive failed checks, so one lost packet or transient network blip doesn’t flag an outage.

SLA target

The availability objective you pick per report (99.5% by default, e.g. 99.9%). Reports compare measured uptime against this target per monitor and flag any monitor that missed it.

Target	Max downtime / 30 days
99%	~7h 18m
99.5%	~3h 39m
99.9%	~43m
99.99%	~4m 20s

Incidents & downtime

An incident opens when a monitor transitions to DOWN (after the 2-check confirmation) and closes when it recovers. Total downtime for a period is the sum of incident durations, maintenance excluded.

Speed

Response time / latency (ms)

Time from sending the request to receiving the complete response, measured per region — a monitor checked from Paris and Frankfurt has one latency series per location. The dashboard shows the latest value and a 24h average; the latency chart plots the full history per region.

Percentiles — P50, P95, P99

Averages hide spikes, so the charts and reports also compute percentiles over the selected window:

• P50 (median) — half of all checks were faster than this. Your “typical” experience.
• P95 — 95% of checks were faster. The experience of your slowest users; the standard SLO number.
• P99 — 99% of checks were faster. Catches rare spikes (GC pauses, cold starts, saturation).

A healthy service keeps P95 close to P50. A widening gap means growing tail latency, usually the first symptom of saturation.

Reliability

MTTR — Mean Time To Recovery

Average duration of an incident: how long it takes, on average, for the service to come back once it goes down. Lower is better — it measures how fast problems get fixed.

MTBF — Mean Time Between Failures

Average time between the start of one incident and the start of the next (computed over the last 30 days). Higher is better — it measures how rarely problems happen.

Read them together: high MTBF + low MTTR = rare, short outages.

LLM-specific metrics

LLM Canary monitors send a real prompt to your provider and measure token streaming:

TTFT — Time To First Token

Time from sending the prompt until the first token arrives. This is the user-perceived “did it start answering?” delay, and usually the first signal of provider-side capacity issues — TTFT drifts upward well before requests actually fail. A check exceeding the configured Max TTFT is flagged degraded even if it eventually completes.

TPOT — Time Per Output Token

Average time between tokens once streaming has started (total generation time ÷ output tokens). It governs how fast the answer “types out” after the first token.

ITL — Inter-Token Latency

The latency between consecutive tokens during streaming. Where TPOT is the average, ITL captures the variance — stutters and stalls mid-generation show up here while TPOT can still look fine.

Certificates & domains

For HTTPS monitors, OKStatus also tracks:

• SSL certificate expiry — days until the certificate expires; alerts fire ahead of time, and reports flag anything under 30 days.
• Domain expiry — days until the domain registration lapses, same thresholds.

Where each metric appears

Metric	Dashboard	Monitor detail	PDF reports
Uptime %	✓	✓ (4 windows)	✓
Response time / latency	✓	✓ (per region)	✓ (avg)
P50 / P95 / P99		✓	✓ (P95/P99)
MTTR / MTBF		✓	✓
TTFT / TPOT / ITL	✓ (LLM)	✓ (LLM)
SSL / domain expiry		✓	✓