Freitag, 14:12 Uhr, Ihr Shop zeigt Zeitüberschreitungen an. Das interne Dashboard schreit, der Support öffnet ein Ticket – und die Statusseite des Hosts bleibt grün. Vierzig Minuten später erscheint ein „Untersuchung läuft“-Banner auf einer Komponente, die Ihnen noch nie aufgefallen ist. Diese Diskrepanz ist kein zeitlicher Zufall: Sie ist oft der erste Hinweis darauf, dass die Statusseite eher der Beruhigung als der Information dient.
Die nützliche Frage lautet also nicht: „Hat mein Host eine Statusseite?“ ". Genauer gesagt: Beschreibt diese Seite wirklich, was wie schnell und mit welchem Detaillierungsgrad bei Ihnen zu Hause kaputt gehen kann, wenn die Krise vorbei ist?
Was eine Statusseite verspricht – und was sie nicht abdeckt
Eine öffentliche Statusseite (Statuspage, Cachet, Inhouse-Lösung) aggregiert den Status vordefinierter Komponenten: API, Panel, DNS, Region, Netzwerk-Backbone. Jede Komponente durchläuft Standardzustände – betriebsbereit, beeinträchtigt, fehlerhaft, Wartung.
Die Falle beginnt, wenn sich der überwachte Perimeter nicht mit Ihrer Architektur überschneidet. Ein VPS in Deutschland kann ausfallen, während nur die Region „Europa“ angezeigt wird. Ein Objektspeicherproblem wird möglicherweise nicht gemeldet, wenn nur das „Kundenpanel“ befolgt wird. Ein gemeinsamer Vorfall bleibt möglicherweise unsichtbar, wenn die Seite nicht zwischen Clustern unterscheidet.
Eine grüne Seite bedeutet nicht „bei Ihnen ist alles in Ordnung“. Es bedeutet „nichts ist auf den Steinen angegeben, die der Gastgeber zeigen möchte“.
Vier Kriterien zur Unterscheidung von Transparenz und Präsentation
Bevor Sie einen „transparenten“ Host klassifizieren, durchlaufen Sie seine Seite durch vier Filter.
1. Komponentengranularität. Werden Regionen, Produkte und Netzwerkschichten explizit benannt? „Cloud-Plattform“ ohne Unterteilung verbirgt lokalisierte Vorfälle.
2. Anamnese und Obduktion. Konsultieren Sie die letzten sechs bis zwölf Monate. Wiederkehrende Vorfälle ohne veröffentlichte Analyse deuten auf eine defensive Kommunikation hin. Datierte Obduktionen mit Angabe der Ursache und Korrekturmaßnahmen sind mehr wert als ein angezeigtes SLA.
3. Veröffentlichungszeitpunkt. Vergleichen Sie den Zeitpunkt Ihrer ersten internen Benachrichtigung mit der ersten öffentlichen Aktualisierung. Eine konstante Lücke von 30 bis 60 Minuten weist häufig auf eine langsame interne Validierung hin – oder darauf, dass die Seite erst dann aktualisiert wird, wenn die Auswirkungen massiv sind.
4. Übereinstimmung mit Ihrem Vertrag. Sind Ihr Angebot, Rechenzentrum und Nebenleistungen (E-Mail, Backup, CDN) in den Komponenten enthalten? Ansonsten betrifft Sie die Seite nur teilweise.
| Signal | Glaubwürdige Transparenz | Beruhigende Vitrine |
|---|---|---|
| Komponenten | Benannte Regionen und Produkte | Sammelformulierungen |
| Geschichte | Datierte, detaillierte Vorfälle | Wenige „aufgelöste“ Einträge oder Vorfälle ohne Kontext |
| Postmortem | Nach erheblichem Ausfall veröffentlicht | Fehlend oder generisch |
| Frist | Update steht kurz vor der Entdeckung | Sichtbare Verzögerung im Vergleich zu Ihren eigenen Sonden |
Was die großen europäischen Player verraten
Die auf dem europäischen Markt sichtbaren Gastgeber spielen nicht alle das gleiche Spiel. OVHcloud veröffentlicht eine nach Produkten und Regionen strukturierte Statusseite mit durchsuchbarem Verlauf – nützlich, vorausgesetzt, Sie überprüfen, ob Ihre Region dort vorhanden ist. Hetzner dokumentiert seine Vorfälle relativ direkt, der Support bleibt jedoch hauptsächlich englisch/deutsch: Die Seite informiert, sie ersetzt keinen Kontakt, der nachts eine Panne hat.
Kleinere Player zeigen manchmal eine minimalistische oder gar fehlende Seite an. Dies ist nicht unbedingt ein Fehler für einen Solo-VPS, der von einem technischen Team verwaltet wird – aber es stellt ein Risiko für ein KMU dar, das den Vorfall über Twitter vor dem offiziellen Banner entdeckt.
Oben: Die Seite sieht nicht, was Sie gerade durchmachen
Folgendes vermeiden Seiten mit „100 % Verfügbarkeit“ fast immer.
Dies ist der Kern der Untersuchung: Viele Teams installieren einen Link zu status.example.com in ihrem Runbook und betrachten das Thema als abgeschlossen. Die eigentliche Frage ist jedoch vertraglicher und technischer Natur: Welche Komponenten werden von wem mit welchem Schwellenwert überwacht und welche Veröffentlichungspflicht besteht tatsächlich?
Entscheide dich und gehe ohne blinden Fleck voran
Öffnen Sie vor der Verlängerung oder Migration die Statusseite Ihrer Auswahllisten und notieren Sie sich drei Dinge: den letzten wichtigen Vorfall, die Zeit zwischen Start und erster Veröffentlichung und ob Ihre Region/Ihr Produkt vorhanden ist oder nicht.
Vergleichen Sie dann kritische Endpunkte mit Ihren eigenen Sonden (Uptime Kuma, Pingdom, Better Stack). Wenn die Lücke regelmäßig mehr als 15 Minuten beträgt, behandeln Sie die Seite als sekundären Kanal.
Um die Spieler und ihre dokumentierten Praktiken zu vergleichen, konsultieren Sie unser Hosting-Verzeichnis und den Vergleicher. Autonome technische Profile tolerieren eine nüchterne Seite; Teams mit Kunden-SLAs benötigen öffentliche Historie und Obduktionen.
Häufig gestellte Fragen
Garantiert eine „grüne“ Statusseite die Abwesenheit von Vorfällen?
Nein. Es zeigt lediglich an, dass zum Zeitpunkt der Beratung keine überwachte Komponente defekt ist. Ein Problem kann sich auf einen nicht aufgeführten Dienst, eine Region, die nicht in den Geltungsbereich fällt, oder einen noch nicht veröffentlichten Vorfall auswirken.
Was sollte ein Gastgeber fragen, bevor er seiner Statusseite vertraut?
Die genaue Liste der überwachten Komponenten, der angestrebte Veröffentlichungszeitpunkt, Zugriff auf die vollständige Historie und ob Ihr Produkt (Region, Angebot, Netzwerkschicht) dort explizit erscheint.
Sollten Sie Statusseitenbenachrichtigungen abonnieren?
Ja, aber als Ergänzung – nicht als einziger Kanal. Querverweis mit Ihren eigenen Sonden, Anwendungsprotokollen und, wenn möglich, alternativen Kanälen (RSS, Webhook, externes Monitoring).
Wie erkennt man eine „Kosmetik“-Statusseite?
Leere oder schlecht detaillierte Historie, zu generische Komponenten („Infrastruktur“), systematische Verzögerungen zwischen Ihrem Vorfall und der ersten Veröffentlichung, fehlende Obduktion nach einem schwerwiegenden Ausfall.
Wenn ein Vertriebsmitarbeiter das nächste Mal „unsere Echtzeit-Statusseite“ erwähnt, bitten Sie ihn nur um eines: Zeigen Sie mir den neuesten Vorfall in meiner Region, mit Angabe des Zeitpunkts seiner Erstveröffentlichung.