Een statuspagina bouwen: componenten, incidenten en uptimecontroles

Een statuspagina laat je gebruikers op één plek zien of je dienst werkt. Om er een te bouwen heb je een lijst met componenten nodig (website, API, betalingen, e-mail), een actuele status voor elk component, incidenten met tijdgestempelde updates, een geschiedenis van eerdere incidenten en eventueel abonnementen, zodat mensen het nieuws krijgen zonder zelf te kijken. De pagina zelf is eenvoudig. De belangrijkste beslissing is waar hij draait: een statuspagina moet blijven werken als je app plat ligt, dus deel geen hosting, database of deploy-pijplijn met het ding waarover hij rapporteert.

Waarvoor een statuspagina dient

Als er iets misgaat, willen gebruikers drie dingen weten: ligt het aan mij, weten jullie ervan, en wanneer is het opgelost. Een statuspagina beantwoordt alle drie zonder een stortvloed aan supporttickets. Het bouwt ook vertrouwen op, want een zichtbare incidentgeschiedenis met eerlijke verslagen laat zien hoe je met problemen omgaat.

Het is geen changelog. Nieuwe functies horen op een changelogpagina; storingen en onderhoud horen hier.

Wat de pagina nodig heeft

Gegevens

Componentstatussen zijn meestal een korte vaste lijst: Operationeel, Verminderde prestaties, Gedeeltelijke storing, Grote storing, In onderhoud.

Pagina's

• Openbare statuspagina: een algemene banner ("Alle systemen operationeel" of de ergste huidige status), elk component met zijn status, eventueel actief incident met de updates, aankomend onderhoud en een strook van 90 dagen met geschiedenis als je controlegegevens hebt.
• Incidentpagina: de volledige tijdlijn van updates voor één incident, met een eigen URL zodat support ernaar kan linken.
• Geschiedenis: eerdere incidenten per maand.
• Abonneren: aanmelden met e-mail, met bevestiging en voorkeuren per component.
• Beheer: een incident aanmaken, updates plaatsen, componentstatussen wijzigen en onderhoud inplannen.

Rechten

Het publiek ziet alles wat gepubliceerd is. Alleen je team kan berichten plaatsen. Houd het beheerdersaccount apart van het inlogsysteem van je hoofdapp als dat kan, zodat een storing bij je authenticatieprovider je niet buitensluit van je eigen statuspagina.

De belangrijkste keuze: houd hem onafhankelijk

Hier gaan de meeste zelfgemaakte statuspagina's mis. Als je statuspagina:

• op dezelfde server of hostingaccount draait als je app,
• uit dezelfde database leest,
• achter dezelfde domeininstellingen of CDN-configuratie zit,
• of door dezelfde pijplijn wordt uitgerold,

dan wordt hij bij veel storingen ook uitgeschakeld, precies wanneer mensen hem nodig hebben. Praktische stappen:

• Aparte hosting. Een ander project of andere provider dan de hoofdapp.
• Eigen subdomein, zoals status.voorbeeld.nl, apart ingesteld in DNS. Zie hoe domeinen en DNS werken.
• Eigen data. Incidenten staan in de eigen opslag van de statuspagina, niet in de database van je app.
• Een statische terugvaloptie. Sommige teams maken de openbare pagina statisch en bouwen hem opnieuw bij elke update, zodat er bijna niets kapot kan gaan.

Handmatige updates of geautomatiseerde controles

Handmatig (begin hier)

Je team plaatst incidenten en wijzigt componentstatussen met de hand vanuit de beheerpagina. Zo werken veel statuspagina's in de praktijk, omdat een menselijke inschatting ("betalingen zijn traag voor sommige kaarttypes") nuttiger is dan een automatisch rood bolletje.

Om snel van problemen te horen, gebruik je een externe uptimemonitor die je app elke minuut of zo controleert en je waarschuwt per e-mail, sms of chat. Veel monitoringdiensten hebben een gratis laag.

Geautomatiseerd

Automatisering betekent dat iets regelmatig elk component controleert en de status bijwerkt. Dat vraagt om code die volgens schema draait, van buiten de infrastructuur van je hoofdapp. Twee gangbare patronen:

• Een externe monitor roept je statuspagina aan via een webhook wanneer een controle faalt of herstelt, en de statuspagina werkt het component bij.
• Een geplande taak in de hosting van de statuspagina pingt elk component en slaat het resultaat op. Controleer hoe je hosting geplande taken afhandelt voordat je hierop vertrouwt; onze gids over achtergrondtaken draaien legt de opties uit.

Geautomatiseerde wijzigingen kunnen heen en weer springen (omhoog, omlaag, omhoog) op een trage verbinding. Eis twee of drie mislukte controles voordat een status verandert, en laat een mens bevestigen voordat een grote storing wordt aangekondigd.

Incidentupdates schrijven

• Plaats vroeg. "We onderzoeken meldingen over mislukte inloggingen" binnen enkele minuten is beter dan een perfect bericht een uur later.
• Zeg wat gebruikers merken, niet wat er intern kapotging.
• Beloof het tijdstip van de volgende update, en houd je eraan.
• Sluit af met een korte samenvatting als het opgelost is: wat er gebeurde, hoe lang het duurde, wat je verandert.

Een eerste prompt die werkt

Bouw een zelfstandige statuspagina voor onze app Parcelio, apart gehost op status.parcelio.com. Componenten: Website, Tracking-API, Meldingen, Betalingen, elk met de status Operationeel, Verminderde prestaties, Gedeeltelijke storing, Grote storing of In onderhoud. De openbare pagina toont een algemene banner met de ergste huidige status, elk component met zijn status, actieve incidenten met tijdgestempelde updates (nieuwste eerst), aankomend onderhoud en een lijst van eerdere incidenten per maand. Elk incident heeft een eigen pagina. Voeg een met wachtwoord beveiligde beheerpagina toe om incidenten aan te maken (titel, impact, getroffen componenten), updates te plaatsen (bericht en status: Onderzoek, Geïdentificeerd, Monitoren, Opgelost), componentstatussen te wijzigen en onderhoud in te plannen. Voeg een POST /api/check-result-endpoint toe dat een componentnaam en omhoog/omlaag van een externe monitor accepteert, beveiligd met een geheim token, en dat een component pas op Verminderde prestaties zet na drie opeenvolgende fouten. Sla alles op in de eigen database van deze app. Eenvoudig, rustig ontwerp dat snel laadt op telefoons.

Bouwstappen

1. Openbare pagina en beheer met handmatige incidenten. Dit alleen is al een werkende statuspagina.
2. Host hem apart en koppel een subdomein.
3. Incidentpagina's en geschiedenis.
4. Onderhoudsvensters.
5. Abonnementen. Aanmelden met dubbele bevestiging per e-mail, en meldingen bij nieuwe incidenten en updates. E-mail heeft een provider nodig; zie hoe je e-mails vanuit je app verstuurt.
6. Monitor-webhook als je geautomatiseerde statuswijzigingen wilt.
7. Voer een oefening uit. Maak een nep-incident aan, plaats updates, los het op, controleer de e-mails en verwijder het daarna.

Veelgemaakte fouten

• Hem bij de app hosten. De meest voorkomende en ernstigste fout.
• Een pagina die altijd "Alle systemen operationeel" zegt. Als hij nooit problemen toont, stoppen gebruikers met hem te vertrouwen.
• Geen tijdstempels of tijdzone. Toon tijden altijd met de tijdzone erbij.
• Vertrouwen op het inloggen van je hoofdapp voor de beheerpagina.
• Stilte tussen updates. "Geen wijziging, we werken er nog aan" is een geldige update.
• Wisselende geautomatiseerde statussen. Eis herhaalde fouten voordat een status verandert.

Wanneer een gehoste statuspaginadienst de betere keuze is

Gehoste statuspaginadiensten zijn gebouwd rond het onafhankelijkheidsprobleem: ze draaien op aparte infrastructuur, verzorgen meldingen voor abonnees per e-mail en sms, en bevatten vaak monitoring en koppelingen met incidenttools. Als uptime deel is van wat klanten betalen, of je contractuele verplichtingen hebt om incidenten te melden, is een speciale dienst meestal de moeite waard. Veel diensten hebben gratis of goedkope lagen voor kleine teams, dus controleer dat voordat je zelf bouwt.

Bouw zelf wanneer je volledige controle wilt over ontwerp en formuleringen, wanneer je behoeften eenvoudig zijn (een handvol componenten, handmatige updates), of wanneer een statuspagina onderdeel is van een product dat je voor anderen bouwt.

Bouwen met Mythex

Bij Mythex kun je de statuspagina als eigen project bouwen, los van je hoofdapp, wat apart hosting en een eigen database geeft. Beschrijf hem in de chat, controleer hem in de live preview, publiceer hem en koppel een subdomein zoals status.jouwdomein.nl (eigen domeinen zijn beschikbaar met Pro). Houd in gedachten dat gepubliceerde Mythex-apps en hun databases in slaapstand gaan als ze niet gebruikt worden en wakker worden bij het volgende bezoek, dus de eerste keer laden na een rustige periode kan trager zijn; een eenvoudige, lichte pagina helpt.

Mythex documenteert geen geplande taken, dus voor geautomatiseerde controles gebruik je een externe uptimemonitor die een webhook-eindpunt in je statuspagina aanroept (zie de webhooks-handleiding). E-mailmeldingen aan abonnees gaan via je eigen provider, met de sleutel opgeslagen als projectgeheim (handleiding e-mail versturen).

Veelgestelde vragen