Vrijdag 14:12 uur geeft uw winkel time-outs weer. Het interne dashboard schreeuwt, ondersteuning opent een ticket – en de statuspagina van de host blijft groen. Veertig minuten later verschijnt er een banner ‘onderzoek in uitvoering’ op een onderdeel dat je nog nooit had opgemerkt. Deze discrepantie is geen toeval van timing: het is vaak de eerste indicatie dat de statuspagina meer dient om gerust te stellen dan om te informeren.
De nuttige vraag is dus niet: “Heeft mijn host een statuspagina?” ". Het is preciezer: beschrijft deze pagina echt wat er in uw huis kan kapotgaan, hoe snel en met welk detailniveau zodra de crisis voorbij is?
Wat een statuspagina belooft — en wat deze niet dekt
Een openbare statuspagina (Statuspagina, Cachet, interne oplossing) verzamelt de status van vooraf gedefinieerde componenten: API, paneel, DNS, regio, netwerkbackbone. Elk onderdeel doorloopt standaardstatussen: operationeel, defect, defect, onderhoud.
De valstrik begint wanneer de bewaakte perimeter niet overlapt met uw architectuur. Een VPS in Duitsland kan uitgevallen zijn terwijl alleen de regio “Europa” wordt weergegeven. Een objectopslagprobleem wordt mogelijk niet gemeld als alleen het “klantenpaneel” wordt gevolgd. Een gedeeld incident kan onzichtbaar blijven als de pagina geen onderscheid maakt tussen clusters.
Een groene pagina betekent niet “alles goed met je”. Het betekent “niets aangegeven op de stenen die de gastheer heeft gekozen om te laten zien”.
Vier criteria om transparantie en showcase te onderscheiden
Voordat u een ‘transparante’ host classificeert, moet u de pagina door vier filters laten gaan.
1. Granulariteit van componenten. Worden regio's, producten en netwerklagen expliciet genoemd? “Cloud Platform” zonder onderverdeling verbergt gelokaliseerde incidenten.
2. Geschiedenis en autopsie. Raadpleeg de laatste zes tot twaalf maanden. Terugkerende incidenten zonder gepubliceerde analyse duiden op defensieve communicatie. Gedateerde lijkschouwingen, met de hoofdoorzaak en corrigerende maatregelen, zijn meer waard dan een getoonde SLA.
3. Publicatietijd. Vergelijk het tijdstip van uw eerste interne waarschuwing met de eerste openbare update. Een consistente pauze van 30 tot 60 minuten duidt vaak op een trage interne validatie – of een pagina die pas wordt bijgewerkt wanneer de impact enorm wordt.
4. Correspondentie met uw contract. Zijn uw aanbod, datacenter en ondersteunende diensten (e-mail, backup, CDN) inbegrepen in de componenten? Anders gaat de pagina slechts gedeeltelijk over u.
| Signaal | Geloofwaardige transparantie | Geruststellende vitrine |
|---|---|---|
| Componenten | Genoemde regio's en producten | Allesomvattende formuleringen |
| Geschiedenis | Gedateerde, gedetailleerde incidenten | Weinig “opgeloste” meldingen of incidenten zonder context |
| Postmortaal | Gepubliceerd na aanzienlijke storing | Afwezig of generiek |
| Termijn | Update bijna detectie | Zichtbare vertraging versus uw eigen sondes |
Wat de grote Europese spelers onthullen
De hosts die zichtbaar zijn op de Europese markt spelen niet allemaal hetzelfde spel. OVHcloud publiceert een statuspagina gestructureerd op producten en regio's, met een doorzoekbare geschiedenis - handig, op voorwaarde dat u controleert of uw regio daar is. Hetzner documenteert zijn incidenten op een relatief directe manier, maar de ondersteuning blijft voornamelijk Engels/Duits: de pagina informeert, het vervangt niet een contactpersoon die 's nachts kapot gaat.
Kleinere spelers vertonen soms een minimalistische of zelfs afwezige pagina. Dit is niet noodzakelijkerwijs een fout voor een solo-VPS die wordt beheerd door een technisch team, maar het is wel een risico voor een MKB-bedrijf dat het incident via Twitter ontdekt vóór het officiële spandoek.
De bovenkant: de pagina ziet niet wat je doormaakt
Dit is wat ‘100% uptime’-pagina’s bijna altijd vermijden.
Dit is de kern van het onderzoek: veel teams installeren een link naar status.example.com in hun runbook en beschouwen het onderwerp als gesloten. De echte vraag is echter contractueel en technisch: welke onderdelen worden gemonitord, door wie, tegen welke drempel, en welke publicatieplicht er eigenlijk bestaat.
Beslis en ga vooruit zonder blinde vlek
Voordat u verlengt of migreert, opent u de statuspagina van uw shortlists en noteert u drie dingen: het laatste belangrijke incident, de tijd tussen start en eerste publicatie en of uw regio/product al dan niet aanwezig is.
Maak vervolgens een kruisverwijzing met uw eigen tests (Uptime Kuma, Pingdom, Better Stack) op kritieke eindpunten. Als de pauze regelmatig groter is dan 15 minuten, behandel de pagina dan als een secundair kanaal.
Om de spelers en hun gedocumenteerde praktijken te vergelijken, raadpleegt u onze hostingdirectory en de vergelijker. Autonome technische profielen tolereren een nuchtere pagina; teams met klant-SLA's hebben openbare geschiedenis en postmortems nodig.
Veelgestelde vragen
Garandeert een “groene” statuspagina de afwezigheid van incidenten?
Nee. Het geeft alleen aan dat er op het moment van consultatie geen bewaakt onderdeel kapot is. Een probleem kan van invloed zijn op een niet-geregistreerde dienst, een regio die niet binnen het bereik valt, of een incident dat nog niet is gepubliceerd.
Wat moet je een host vragen voordat je zijn statuspagina vertrouwt?
De exacte lijst met bewaakte componenten, het beoogde publicatietijdstip, toegang tot de volledige historie en of jouw product (regio, aanbod, netwerklaag) daar expliciet in voorkomt.
Moet u zich abonneren op waarschuwingen op de statuspagina?
Ja, maar als aanvulling – niet als het enige kanaal. Kruisverwijzingen met uw eigen probes, applicatielogboeken en, indien mogelijk, alternatieve kanalen (RSS, webhook, externe monitoring).
Hoe herken ik een “cosmetische” statuspagina?
Lege of slecht gedetailleerde geschiedenis, te algemene componenten (“Infrastructuur”), systematische vertragingen tussen uw incident en de eerste publicatie, afwezigheid van autopsie na een grote mislukking.
De volgende keer dat een verkoper 'onze realtime statuspagina' vermeldt, vraagt u slechts één ding: laat me het laatste incident in mijn regio zien, met de tijd waarop het voor het eerst werd gepubliceerd.