Om 9.12 uur reageerde de site niet meer. Om 09:45 uur maakt iemand een notiepagina 'Incidentstatus in uitvoering'. Om 10.30 uur hadden klanten de ondersteuning – en sociale media – al overspoeld vanwege het ontbreken van één enkel kanaal. De statuspagina is geen post-mortem luxe: het is een vertrouwensinfrastructuur die moet worden opgebouwd als alles goed gaat.
Een openbare statuspagina toont de status van uw services, incidentgeschiedenis en waarschuwingsabonnementen. Als het goed wordt gedaan, ontlast het de steun en kadert het de incidentcommunicatie. Slecht gedaan – of onder stress gecreëerd – zorgt voor verwarring.
Wat een nuttige pagina bevat
| Element | Rol | Veel voorkomende fout | |
|---|---|---|---|
| Onderdelen uitgesneden | Site, API, e-mail – geen “alles”-blok | Wereldwijd groen licht terwijl de betaling KO | is |
| Geschiedenis 90 dagen | Bewijs van ernst | Lege pagina na elk incident | |
| Abonnementen e-mail/RSS/webhook | Klanten geïnformeerd zonder te bellen | Geen link van voettekst of ondersteuning | |
| Gepland onderhoud | Vermindert “is het naar beneden?” kaartjes » | Pas de dag ervoor aangekondigd | |
| Aparte accommodatie | Blijf op als je naar beneden prikt | Status op dezelfde VPS als de site |
Veelgebruikte tools: Statuspage (Atlassian), Cachet, Instatus of Europese SaaS volgens GDPR-beperkingen. De host kan ook een pagina leveren — nuttig voor zijn infrastructuur, onvoldoende voor uw stapel.
Bereid je voor op het incident: minimaal runbook
Vermeld de componenten met de technische eigenaar en contactpersoon. Definieer wie publiceert – een bij naam genoemde persoon, niet het vage “team”. Berichtsjablonen schrijven: onderzoeken, identificeren, monitoren, opgelost. Test een nep-kwartaalstoring met abonnee-updates en -meldingen. Koppel de pagina van de site (voettekst, ondersteuningspagina) en de ondersteuningshandtekening.
Tijdens het incident volgt elke update de regel: zeg wat je weet, markeer wat je niet weet, wis de tijdstempel. Geen “alles is geregeld” vóór het bewijs.
Verbind monitoring en status
Automatiseer wat kan zijn: HTTP-tests op kritieke URL's (homepage, /health, API checkout), Prometheus- of UptimeRobot-waarschuwingen voor de webhookstatus. Voorkom dat het automatisch ‘opgelost’ wordt zonder menselijke validatie.
De uptime SLA van de host vervangt uw eigen applicatietests niet.
Bovenaan: de statuspagina is een impliciet contract met uw gebruikers
Hosts met een publieke status (OVH, Scaleway, etc.) geven een voorbeeld aan de infrastructuurkant; het blijft jouw verantwoordelijkheid om de business impact te vertalen.
Beslis en ga vooruit zonder blinde vlek
Kies een tool die buiten uw hoofdproductie wordt gehost. Knip vier tot zes componenten uit die zichtbaar zijn aan de kant van het vaartuig. Train een oproepposter en schrijf berichtsjablonen. Plan een halfjaarlijkse oefening: valse mislukking, melding, timing. Vergelijk hosts met de openbare statusgeschiedenis via de overzicht.
Veelgestelde vragen
Heb ik een pagina nodig als de host er een heeft?
Ja voor uw applicatielaag: verlopen certificaat, WordPress, API, betalingstunnel. De OVH- of AWS-status zegt niet of uw zakelijke service werkt.
Welke componenten moet je vermelden?
Wat de gebruiker ziet of wat een bestelling blokkeert: openbare site, API, backoffice, transactionele e-mails, DNS.
Dezelfde host voor status en site?
Riskant: als het datacenter valt, valt de pagina mee. Geef de voorkeur aan een externe SaaS of een andere regio.
Updatefrequentie incidenten?
Minimaal elk kwartier tot dertig minuten met grote impact, ook zonder aanwijsbare oorzaak. Stilte voedt geruchten.
Stel uw statuspagina in op een rustige dag. Op de dag van de inzinking zul je noch de tijd noch het brein hebben om het uit te vinden – alleen om het te vullen.