Hoe een goede openbare statuspagina eruitziet

Een openbare statuspagina is de plek waar klanten naartoe gaan tijdens een storing. Een goede statuspagina vermindert het aantal supporttickets en bouwt vertrouwen op. Waaruit hij bestaat.

Wat een goede statuspagina moet hebben

De actuele staat van elke kerndienst. Niet alleen "alles OK", maar opgesplitst per component (API, web, dashboard, emailing, payment processing).
Incidentgeschiedenis van de laatste 90 dagen. Zonder iets te willen verbergen - een transparante geschiedenis bouwt vertrouwen op.
Een uptime-metriek (meestal over 30 dagen) voor elke component, uitgedrukt als een transparant percentage.
Geplande onderhoud. Een banner met de datum en een beschrijving van wat niet beschikbaar zal zijn.
Actief incident met een tijdlijn van updates. Investigating → Identified → Monitoring → Resolved.
Een aanmeldformulier. Klanten krijgen een e-mail wanneer de status verandert en hoeven de pagina niet herhaaldelijk te controleren.

Een duidelijke componenthiërarchie

In plaats van één "monitor"-record splits je de dienst op in componenten die zinvol zijn vanuit het oogpunt van de klant:

Web App - frontend (gebruikt door bezoekers)
API - backend voor programmatische integraties
Auth / Login - inloggen
Email delivery - transactionele e-mails
Background jobs - sync, facturering, exports
Status page - meta-component: ook de statuspagina zelf kan uitvallen (daarom zou hij op een andere infrastructuur dan het product moeten draaien)

Incident communication: anatomie van een goede update

Houd je bij een echte storing aan deze fasen:

Investigating - "We hebben een probleem met [component] geïdentificeerd. Het team onderzoekt de oorzaak." (binnen 5 min na detectie)
Identified - "De oorzaak is [kort]. We werken aan een fix. ETA [tijd]." (zodra je weet wat het probleem veroorzaakt)
Monitoring - "We hebben een fix uitgerold. We houden in de gaten of het probleem zich niet herhaalt." (na het uitrollen van de oplossing)
Resolved - "Het incident is opgelost. Duur X minuten. Er volgt een postmortem." (na bevestigd herstel)

Elke fase krijgt een timestamp en een eigen update. Publiceer na het incident een post-mortem (root cause, timeline en maatregelen die herhaling voorkomen).

Regel: Gebruik nooit vage frasen zoals "experiencing some issues". Klanten willen concreetheid: "Inloggen mislukt bij ~30 % van de pogingen. De API werkt normaal. Het web is alleen beschikbaar in read-only modus."

Hosting: het principe van onafhankelijke infrastructuur

De statuspagina moet op een andere infrastructuur draaien dan de gemonitorde dienst. Als je AWS-regio uitvalt, valt een in dezelfde regio gehoste statuspagina mee uit - precies op het moment dat klanten hem het hardst nodig hebben.

Praktische oplossingen:

Hosting via een externe SaaS (ePulz.io, Better Stack, Atlassian Statuspage)
Een eigen statische pagina op een CDN (Cloudflare Pages, Netlify) met het API-endpoint elders
In het uiterste geval een minimale statische pagina op Cloudflare met handmatig bijgewerkte tekst

Subscribers: e-mail en webhook

Klanten willen de statuspagina niet voortdurend verversen. Een goede pagina ondersteunt daarom:

Email subscribers - in ePulz.io beschikbaar voor ingelogde gebruikers met een betaald plan (we verzamelen abonnementen alleen van geverifieerde accounts, niet van anonieme bezoekers)
Webhook - voor teams die de status willen integreren in hun eigen Slack of PagerDuty

Anti-pattern: problemen verbergen

De verleiding om een storing als "degraded" te markeren in plaats van "down" (of hem helemaal niet te tonen) is groot, maar kortzichtig:

Klanten merken de storing toch wel (via hun eigen monitoring, supporttickets of social media)
Je verliest vertrouwen wanneer ze ontdekken dat de status "OK" meldt tijdens een duidelijke storing
Je verliest het reële beeld van de uptime-trend, die je nodig hebt voor interne besluitvorming

De beste strategie is radicale transparantie. GitLab, Cloudflare en Stripe publiceren allemaal gedetailleerde post-mortems, zelfs bij gênante fouten, en de community waardeert dat.

SEO en brand

Een statuspagina zou:

Op een stabiele en makkelijk te onthouden URL voor de dienststatus moeten staan
Een eigen branding (logo, kleuren) moeten hebben - de klant moet zien dat hij nog steeds op jouw pagina is
Geïndexeerd moeten zijn in Google (betere zichtbaarheid bij het zoeken op "[brand] down")
Vanaf de hoofdsite gelinkt moeten zijn (footer "Dienststatus")

Conclusie

Een statuspagina is geen decoratie. Het is een operationeel hulpmiddel dat tijdens een incident de supportbelasting vermindert en op lange termijn vertrouwen opbouwt. Een paar uur investeren in de juiste configuratie betaalt zich terug bij de eerste grote storing.

Maak een statuspagina in 5 minuten

ePulz.io statuspagina's met eigen branding, email subscribers en incident timeline. 7 dagen gratis.

ePulz.io proberen →