Gapless

Metrics and SLOs

The metrics that describe the assistant's health, how to define service level objectives users actually feel, and which conditions should page someone.

Metrics show the state of the whole system over time. SLOs (service level objectives) turn the most important metrics into explicit promises, and alerts fire when those promises are at risk.

Core metrics

User-facing

MetricTypeDimensions
Chat requestsCounterTenant, feature, outcome
Time to first tokenHistogramTenant, model route, region
Total response timeHistogramFeature, model route
Outcome rateCounter by outcomeanswered, not_found, blocked, failed, stopped
Stream dropsCounterRegion, client type
Error rate by codeCounterError code from Errors

Model layer

MetricTypeDimensions
Model callsCounterProvider, model, route, status
Model latency and TTFTHistogramProvider, model
Tokens in, out, cachedCounterProvider, model, tenant, feature
CostCounterProvider, model, tenant, feature
Fallback rateCounterRoute, reason
Provider 429 and 5xxCounterProvider, model, region
Circuit breaker stateGaugeProvider, model

Retrieval and ingestion

MetricType
Retrieval latency, by stageHistogram
Low relevance rate (top score below threshold)Counter
Index freshness lagHistogram per connector
Queue depth and oldest item ageGauge per stage
Ingestion failures by reasonCounter

Safety and tools

MetricType
Guardrail blocks by guardrail and categoryCounter
Injection detectionsCounter
Tool calls by tool and confirmation resultCounter
Agent step limit hitsCounter
Chunks without ACL encounteredCounter. Must stay at zero

Be careful with high-cardinality dimensions. Tenant ID is fine for most metrics systems with hundreds or a few thousand tenants. User ID, conversation ID, and trace ID belong in traces and logs, not metric labels.

Service level objectives

An SLO states a target for a measurable indicator over a time window. Choose a few that reflect what users experience.

SLI (indicator)SLO (target)Window
Share of chat requests that return a non-error outcome99.5%30 days
Share of chat requests with TTFT under 3 s95%30 days
Share of chat requests with TTFT under 8 s99%30 days
Share of permission revocations reflected in the index within 15 minutes99%30 days
Share of uploads ready to query within 2 minutes (files under 20 MB)95%30 days

Notes:

  • Count not_found and blocked as successes for availability. They are correct behavior. Track them separately as quality signals.
  • Exclude user cancellations from latency SLOs.
  • Model provider outages count against your SLO. Users do not care whose fault it is. This is the business case for fallbacks.

Error budgets

A 99.5% availability SLO over 30 days allows 0.5% failures: the error budget. If you spend it quickly, slow down risky changes, such as model migrations, and focus on reliability. If you have plenty left, you can take more risk.

Alerting

Page a human only for problems that need action now. Alert on SLO burn rate rather than raw thresholds: a burn rate alert fires when you are consuming the error budget fast enough to exhaust it soon.

AlertCondition (example)Severity
Availability fast burnError budget burning 14 times faster than allowed, over 1 hourPage
Availability slow burnBurning 6 times faster, over 6 hoursPage during working hours
TTFT degradationp95 TTFT over 5 s for 15 minutesPage
All providers failing for a routeFallback chain exhausted above 1% of requests for 5 minutesPage
Chunk without ACLAny occurrencePage security on-call
Permission sync lagp95 over 15 minutes for 30 minutesPage during working hours
Cost spikeHourly cost over 3 times the same hour last weekNotify
Guardrail block spikeBlock rate doubles versus baseline for a tenantNotify
Ingestion queue stuckOldest item over 1 hour in a high-priority queueNotify, page if uploads are affected
Provider rate limitsSustained 429s above 5%Notify

Every alert links to a runbook. See Runbooks and incidents.

Dashboards

Build a small number of dashboards with a clear purpose:

DashboardAudienceShows
Service overviewOn-call, everyoneSLOs, request rate, outcome mix, TTFT, errors, provider status
Model layerAI engineersCalls, latency, tokens, cost, fallbacks by provider and model
Retrieval and ingestionAI and data engineersRetrieval latency and relevance, freshness, queues, failures
QualityAI team, productFeedback, regenerations, sampled grades, not found rate. See Quality monitoring
CostEngineering leads, financeCost by tenant, feature, model, trend and forecast
Tenant viewSupport, account teamsOne tenant's usage, errors, latency, and limits

Add deploy and config change markers to every dashboard. Most metric changes line up with a deploy, a prompt version change, or a model route change.

Checklist

  • User-facing, model, retrieval, ingestion, safety, and tool metrics are collected with consistent dimensions.
  • High-cardinality IDs are kept out of metric labels.
  • SLOs cover availability, TTFT, permission sync, and upload readiness.
  • not_found and blocked count as successes for availability.
  • Alerts use burn rates, and every alert links to a runbook.
  • A chunk without an ACL pages security immediately.
  • Dashboards show deploy and config change markers.

On this page