SLO et budget d'erreur

Un SLO (objectif de niveau de service) est la disponibilité que vous visez, par exemple 99,9 % sur 30 jours. OKStatus en tire un budget d’erreur — la panne que cet objectif autorise —, affiche ce qu’il en reste et vous prévient avant qu’il soit épuisé.

Disponible avec les offres Max et Enterprise. Il n’y a qu’un réglage : l’objectif. La fenêtre (30 jours glissants), le budget et les alertes en découlent.

SLA ou SLO ?

Le SLA est ce que vous promettez à vos clients ; c’est ce que mesurent les rapports SLA. Le SLO est votre objectif interne, en général plus strict, pour réagir avant que le SLA soit menacé. Fixer un SLO ne change rien à vos rapports.

Le budget d’erreur

Le budget est la panne que l’objectif autorise sur 30 jours :

Objectif	Panne autorisée sur 30 jours
99 %	7 h 12 min
99,5 %	3 h 36 min
99,9 %	43 min
99,95 %	21 min

Tout objectif entre 50 % et 99,999 % est accepté.

Ce qui compte

Seulement les pannes, décidées exactement comme pour l’uptime : un monitor est en panne quand la majorité de ses régions confirme l’échec. Un monitor lent n’est pas en panne — la lenteur relève des alertes de temps de réponse.
Les maintenances planifiées ne comptent pas : la panne survenue pendant une fenêtre de maintenance du monitor est écartée.
La fenêtre glisse : elle couvre toujours les 30 derniers jours. Une panne rend son temps 30 jours plus tard, le budget se reconstitue tout seul.
La disponibilité affichée sur les écrans SLO vaut 1 − panne ÷ 30 jours : « objectif tenu » et « budget restant » ne peuvent pas se contredire.

Fixer l’objectif d’un monitor

Ouvrez le monitor (Modifier, ou Ajouter un monitor) et allez à l’étape Alertes. Sous Objectif de disponibilité (SLO), choisissez 99 %, 99,5 %, 99,9 % ou 99,95 %, ou saisissez votre valeur. Le formulaire affiche le budget correspondant (« 43 min de panne autorisées sur 30 jours ») et, pour un monitor existant, si l’objectif aurait été tenu sur les 30 derniers jours. Aucun retire le SLO.

Fixer l’objectif d’un groupe

Un groupe représente souvent un service : « Paiement » = API + webhooks + back-office. Ouvrez le groupe (⋯ → Modifier) et choisissez son objectif. La règle est simple : le groupe est en panne dès qu’un de ses monitors l’est. Deux monitors en panne en même temps comptent une seule fois. Chaque monitor garde son propre SLO s’il en a un.

Les alertes du groupe partent sur les canaux d’alerte du groupe, réglés dans la même fenêtre.

Beaucoup de monitors d’un coup

Sur la page SLO, choisissez Définir des SLO (ou le menu Type → Sans SLO et le bouton de sélection), cochez les monitors, choisissez un objectif et Appliquer. Avant d’appliquer, la liste indique pour chaque monitor s’il aurait tenu cet objectif sur les 30 derniers jours.
Sur la liste des Monitors, sélectionnez des monitors et utilisez SLO ▾ dans la barre de sélection, à côté de Groupe ▾.
Pour un grand parc, réglez sloTarget par l’API ou Terraform (voir plus bas).

Où lire le budget

La page SLO (sidebar, sous Monitors) : tous les SLO, monitors et groupes, le pire en haut — objectif, disponibilité sur 30 jours, budget restant et date d’épuisement au rythme actuel. La rangée de KPI compte les SLO tenus, en danger et épuisés.
La page du monitor : la barre de période affiche le SLO du monitor à la place de l’objectif SLA de l’organisation, et une carte Budget d’erreur montre ce qui reste, la panne consommée, la projection et le budget restant sur les 30 derniers jours.
L’en-tête de groupe de la liste des monitors : « SLO 99,5 % · budget 71 % ».

Un SLO est en danger quand il reste moins de 25 % de son budget, ou quand il serait épuisé sous 7 jours au rythme des 7 derniers jours.

Alertes

Trois alertes, rien à régler. Elles partent sur les canaux du monitor (ou du groupe), une au plus par évaluation (toutes les 5 minutes) :

Alerte	Envoyée quand
Fond vite	2 % du budget de 30 jours perdus dans la dernière heure, ou 5 % dans les 6 dernières heures (et au moins une minute de panne). Répétée au plus toutes les 6 h.
75 % consommé	Les trois quarts du budget sont partis. Renvoyée seulement après être repassé sous 70 %.
Épuisé	L’objectif n’est plus tenu. Renvoyée seulement après être repassé sous 90 %.

Il n’y a pas de message « rétabli » : le budget revient lentement, tout seul, et un message pour cela serait du bruit. Pas d’escalade non plus — une alerte SLO est un avertissement, pas un incident. Un monitor en pause ou en sourdine n’en envoie pas.

Les alertes SLO partent vers l’e-mail, les webhooks et les messageries (Slack, Discord, Microsoft Teams, Google Chat, Mattermost, Rocket.Chat, Telegram, ntfy, Pushover). Les outils d’incident (PagerDuty, Jira, Jira Service Management, incident.io, Alertmanager, Splunk, Grafana IRM), les SMS et le push mobile ne les reçoivent pas : ils servent à réveiller quelqu’un, et une alerte de budget n’est pas faite pour ça.

Pages de statut

Les SLO et les budgets ne sont jamais affichés sur les pages de statut publiques.

Offres

Sous Max, le bloc SLO des formulaires et la page SLO sont visibles mais verrouillés, avec un lien vers les offres. Si l’organisation passe à une offre inférieure, ses SLO sont conservés mais ne sont plus évalués, et on peut toujours les retirer.

API, Terraform et MCP

Quoi	API REST	Terraform	MCP
Objectif d’un monitor	`sloTarget` sur les monitors (`null` le retire)	`slo_target` sur `okstatus_monitor`	`slo_target` sur `create_monitor`, `update_monitor`
Objectif d’un groupe	`sloTarget` sur les groupes de monitors	`slo_target` sur `okstatus_monitor_group`	`update_monitor_group`
Budgets	`GET /api/v1/slos`, `GET /api/v1/monitors/:id/slo`	—	`list_slos`

Terraform gère l’objectif, pas le budget : un chiffre qui change à chaque minute n’a rien à faire dans un état Terraform.