Wat een goede statuspagina meldt tijdens een incident

Een goede statuspagina meldt tijdens een incident vier dingen, in deze volgorde: wat er getroffen is, hoe ernstig het is, wat je op dit moment weet en wanneer je meer laat weten. Er staat niet op wie er on-call is, welke server zich misdraagt en er staat geen link naar je interne runbook. Die informatie hoort ergens anders, en als je die op de publieke pagina zet, verwar je klanten of lekt er informatie uit die je niet wilde delen.

De meeste teams doen de publieke helft goed, maar lossen de tweede helft nooit op: waar moet de informatie voor de responder dan wél staan? In dit artikel behandelen we allebei.

Wat klanten echt willen lezen

Een update op je statuspagina doet zijn werk als een gestreste, niet-technische lezer binnen vijf seconden kan beantwoorden: "Heb ik hier last van, en wanneer is het opgelost?" Dat betekent:

• Welke services getroffen zijn, genoemd zoals klanten ze kennen ("Checkout", niet "payments-worker-3").
• De huidige ernst, in gewone woorden: verminderde prestaties, gedeeltelijke storing of grote storing, niet een interne ticketprioriteit.
• Wat je tot nu toe weet, in begrijpelijke taal, zonder intern jargon en zonder schuld toe te wijzen.
• Een tijdstip voor de volgende update, ook als die volgende update luidt: "we zoeken het nog uit".

De meeste statuspagina's (ook de grote: die van GitHub en Cloudflare volgen allebei dit patroon) laten een incident tijdens het verloop door een klein aantal statussen gaan:

Dit is geen formele standaard (er bestaat geen RFC voor de formulering op statuspagina's), maar het is toch een conventie die je het beste kunt volgen, omdat je klanten die al hebben leren lezen bij elke andere SaaS-tool die ze gebruiken. Een eigen vocabulaire bedenken zorgt alleen voor extra frictie, precies op het moment dat mensen duidelijkheid willen.

TipPlaats updates met een vaste regelmaat, ook als het alleen "geen verandering, we zoeken het nog uit" is, in plaats van stil te blijven tussen mijlpalen. Stilte komt over alsof je het hebt opgegeven, ook als er achter de schermen hard gewerkt wordt.

Waarom de klantversie niet werkt voor je team

Het probleem: de pagina voor klanten is bewust onvolledig. Voor hen is dat juist, maar voor degene die het probleem daadwerkelijk oplost is ze nutteloos. Een responder die om 3 uur 's nachts wordt opgepiept, heeft niets aan "we onderzoeken een probleem met de checkout". Die wil weten welke regio's het melden, hoe oud de laatste check is, wie er al mee bezig is en waar het runbook voor precies die service staat.

Teams lossen dit nu op door die informatie ergens anders te bewaren: een wikipagina, een vastgepind Slack-bericht, een spreadsheet met on-call-namen. En dan maar hopen dat degene die wordt opgepiept het snel genoeg vindt. Dat is het gat dat een statuspagina nooit heeft gedicht: ze vertelt klanten dat er iets stuk is, maar is nooit gebouwd om je eigen team te vertellen hoe je het oplost.

Wat een statuspagina je team in plaats daarvan moet laten zien

Een statuspagina heeft het ruwe signaal al: ze is gebouwd op je monitoring-checks en weet dus precies welke service down is, welke regio's nog rapporteren en hoe lang al. Wat ontbreekt is niet meer monitoring, maar een tweede weergave van dezelfde pagina, geschreven voor de mensen die het probleem oplossen in plaats van voor de mensen die er last van hebben.

Dat is wat de Team view van InfraNest is. Open een willekeurige statuspagina en je vindt er een tweede weergave van, achter je normale login, die het volgende toont:

• De balk bovenaan: de algehele status, hoeveel services van de pagina up zijn, de uptime over 30 dagen en wanneer het volgende onderhoudsvenster begint.
• On call: vrije tekst, omdat een rooster een product op zich is; de meeste teams hebben genoeg aan een naam, een nummer en een kanaal.
• Open right now: elk incident dat op dit moment loopt, elk met een link naar de publieke beschrijving. Dat is de link die je daadwerkelijk in een supportticket plakt.
• Services, last 30 days: precies gegroepeerd zoals klanten ze zien, met uptimebalken, wanneer elke service voor het laatst is gecontroleerd, hoeveel monitoringregio's nog rapporteren en een Runbook-knop voor elke service die er een heeft.

Noch het on-call-contact noch de runbooklinks komen ooit op de publieke pagina terecht. Ze worden alleen getoond aan mensen die zijn ingelogd bij je organisatie. Een klant die toevallig het wachtwoord van je pagina kent, ziet dus nog steeds alleen de publieke pagina en verder niets. De weergave ververst zichzelf bovendien elke 30 seconden, zodat je die gerust het hele incident lang open kunt laten staan op een tweede scherm.

Instellen

Beide onderdelen staan op dezelfde plek als de statuspagina zelf:

1. Ga naar Status Pages en open de pagina.
2. Vul On-call contact in: een naam, een telefoonnummer, een link naar je PagerDuty-rooster of een Slack-kanaal. Maak het veld leeg wanneer iemand uit het rooster gaat; een verouderde naam hier is precies de reden dat de on-call van vorig kwartaal steeds wordt opgepiept.
3. Open het tabblad Components, klik op een service en vul Runbook link in. Laat die verwijzen naar het document voor die service, niet naar de voorpagina van je wiki. Het hele idee is dat degene die wordt opgepiept op de juiste pagina belandt, niet op een index waarin hij moet zoeken.

De runbooklink moet beginnen met https://. Beide maken deel uit van privéstatuspagina's. Als je abonnement de team view niet bevat, meldt de pagina dat en blijft al het andere werken zoals voorheen.

Een voorbeeldincident, op twee manieren verteld

Hetzelfde incident, twee doelgroepen:

Publieke pagina (voor klanten):

Investigating — We zien verhoogde foutpercentages bij Checkout. We zoeken het uit en plaatsen binnen 30 minuten een update.

Team view (op hetzelfde moment):

Checkout: 2 van 3 regio's melden down, laatst gecontroleerd 14s geleden. On call: Priya, +44 7xxx, #incidents. Runbook: checkout-5xx-playbook.

De eerste versie is rustig, klopt en vertelt een klant precies zoveel als hij moet weten. De tweede is compact en specifiek, en zet een responder in beweging zonder één enkel Slack-bericht met de vraag "weet iemand wie hier eigenaar van is?"

WarningPlak geen interne details, zoals servernamen, aantallen regio's of on-call-namen, in de publieke incidentupdate. Het helpt de lezer niet, en het is weer iets dat je later moet weglakken als de pagina ooit extern wordt gedeeld.

Zodra het incident is opgelost, houdt de publieke beschrijving haar eigen permanente URL. Dat is handig, omdat supporttickets die ernaar verwijzen vaak nog lang openstaan nadat de pagina zelf al met het volgende bezig is. Als je die links naar je ticketsysteem doorstuurt, lees dan statuspagina-incidenten koppelen aan supportgesprekken.

Korte checklist voor het instellen

• Een statuspagina die is opgebouwd uit je echte monitors, niet met de hand ingetypt: zie een statuspagina maken.
• Een on-call-contact dat op de pagina is ingevuld en actueel wordt gehouden.
• Een runbooklink bij elke service die er een heeft.
• Een vaste updatefrequentie die je met je team hebt afgesproken, ook voor updates als "nog geen verandering".

Veelgestelde vragen

Wil je het volledige plaatje voordat je er een opzet? Begin bij statuspagina's.