Website down: Die Checkliste für den Ernstfall.
Stand 11. Juli 2026 · 7 Min. Lesezeit
Wenn die eigene Website nicht erreichbar ist, zählt Reihenfolge mehr als Hektik. Diese Checkliste führt vom ersten Alarm bis zur Nachbereitung, damit du in der Situation nichts vergisst, in der man am ehesten etwas vergisst.
Inhalt
Schritt 1: Verifizieren statt raten
Erst sicherstellen, dass es wirklich ein Ausfall ist und kein lokales Problem: Seite aus einem zweiten Netz aufrufen (Handy ohne WLAN reicht) und ins Monitoring schauen. Ein guter Monitor sagt dir nicht nur "down", sondern auch WIE down: Timeout, DNS-Fehler, Zertifikatsfehler oder ein konkreter Statuscode. Diese Fehlerart ist der Wegweiser für alles Weitere.
Schritt 2: Die schnellen Checks, in dieser Reihenfolge
- Statusseite des Hosters/Cloud-Anbieters öffnen: Ist es eine bekannte Störung, sparst du dir die eigene Fehlersuche.
- Letzte Änderung zurückdenken: Deployment, Config-Änderung, Plugin-Update, DNS-Umzug in den letzten Stunden? Der häufigste Täter ist die letzte Änderung.
- DNS prüfen (dig/nslookup auf deine Domain): Zeigt der A-/AAAA-Record noch auf den richtigen Server? Ist die Domain womöglich abgelaufen?
- Zertifikat prüfen: Browser-Fehlermeldung oder Monitoring sagen es dir direkt. Abgelaufenes Zertifikat heißt: Renewal-Job kontrollieren.
- Server erreichbar? SSH drauf: Läuft der Webserver-/App-Prozess, ist die Platte voll (df -h), ist der Arbeitsspeicher am Limit?
- Logs lesen: Webserver-Error-Log und Anwendungs-Log der letzten Minuten, nicht raten, nachsehen.
Fehlerbild und wahrscheinlichste Ursache
| Fehlerbild | Wahrscheinlichste Richtung |
|---|---|
| DNS-Fehler | Domain/Nameserver: Record geändert, Domain abgelaufen, Umzug unvollständig |
| Zertifikatsfehler | Renewal fehlgeschlagen (certbot & Co.), falsches Zertifikat nach Umzug |
| Timeout / keine Antwort | Server aus oder überlastet, Firewall, Prozess hängt |
| 502 / 504 | Reverse-Proxy erreicht die App nicht: Prozess tot, Deployment-Lücke |
| 500 | Fehler in der Anwendung: letztes Deployment, Config, Datenbank |
| 503 | Wartungsmodus aktiv (gewollt?) oder Überlastschutz greift |
| 200, aber Seite falsch/leer | Soft-Fehler: CMS/Datenbank liefert Leeres, CDN-Cache, halbes Deployment |
Schritt 3: Kommunizieren, bevor gefragt wird
Sobald klar ist, DASS es einen Ausfall gibt (nicht erst, wenn die Ursache gefunden ist): Statusseite aktualisieren. Ein ehrliches "Wir haben eine Störung und arbeiten daran" zum frühen Zeitpunkt wirkt professioneller als perfekte Erklärungen eine Stunde später.
Vorsicht mit Zeitversprechen: Eine ETA, die du reißt, ist schlimmer als keine. Besser: regelmäßige kurze Updates ("nächstes Update in 30 Minuten"), auch wenn der Stand unverändert ist.
Schritt 4: Nachbereitung, das eigentlich Wertvolle
Nach der Entwarnung: Ursache in zwei, drei Sätzen dokumentieren (was, warum, wie behoben), Ausfallzeitraum festhalten und die eine Frage beantworten: Welche Änderung sorgt dafür, dass genau das nicht wieder passiert oder schneller auffällt?
Für Kundenprojekte lohnt ein exportierbarer Nachweis des Zeitraums. Bei Clesk Uptime sind die Prüfprotokolle kryptografisch signiert, damit lässt sich später belegen, wann geprüft wurde und was die Checks ergaben.
Häufige Fragen
Wie schnell sollte ich kommunizieren?
Als Faustregel: innerhalb weniger Minuten nach der eigenen Bestätigung des Ausfalls, spätestens bevor die ersten Kunden anrufen. Die Statusseite mit einem Zweizeiler zu aktualisieren dauert 60 Sekunden.
Was sage ich Kunden, wenn ich die Ursache noch nicht kenne?
Genau das: Störung bestätigt, Team dran, nächstes Update um Uhrzeit X. Kunden verzeihen Ausfälle deutlich eher als Funkstille.
Wie übe ich den Ernstfall?
Einmal die Checkliste im Trockenlauf durchgehen: Hast du SSH-Zugang parat, kennst du die Hoster-Statusseite, kann jeder im Team die Statusseite aktualisieren? Die Lücken findest du besser jetzt als um 2 Uhr nachts.
Der erste Schritt passiert vor dem Ausfall.
Monitoring in zwei Minuten einrichten, mit Statusseite für die Kommunikation im Ernstfall.
Kostenlos überwachen