Ausfallursachen von Websites: Gründe und Gegenmittel

Welche Ursachenklassen gibt es für Website-Ausfälle?

Ein Ausfall bedeutet aus Sicht der Besucher: Die Seite lädt nicht, liefert einen Fehler oder ist unbenutzbar langsam. Aus Sicht des Betreibers kann die Ursache an sehr verschiedenen Stellen liegen, und genau diese Vielfalt macht die Fehlersuche mühsam. Es hilft, den Weg einer Anfrage zu betrachten: Der Browser löst den Namen per DNS auf, baut eine Verbindung zum Server auf, handelt TLS aus, sendet eine HTTP-Anfrage, der Webserver reicht sie an die Anwendung weiter, die Anwendung fragt die Datenbank und womöglich externe Dienste. An jedem dieser Glieder kann es haken.

Wir ordnen die Ursachen deshalb nach Ebene. Welche Klasse bei Ihnen am häufigsten vorkommt, hängt von Betrieb, Hosting und Software ab; belastbare Prozentwerte für „die“ häufigste Ursache nennen wir bewusst nicht, weil sie vom Einzelfall abhängen und uns keine geprüfte Branchenstatistik vorliegt. Stattdessen finden Sie unten Symptome, Gegenmaßnahmen und Diagnosebefehle.

Wie führen Server- und Hosting-Probleme zum Ausfall?

Die klassische Ursache ist Ressourcenmangel. Ein Server hat endlichen Arbeitsspeicher, Plattenplatz und eine begrenzte Zahl gleichzeitig bearbeiteter Anfragen. Wird eine dieser Grenzen erreicht, bricht der Dienst nicht langsam ab, sondern oft schlagartig.

• Festplatte oder Inodes voll: Logdateien, Backups oder Cache-Verzeichnisse wachsen unbemerkt. Symptome: Fehler wie No space left on device, Uploads scheitern, Datenbank bricht ab. Prüfen mit df -h (Platz) und df -i (Inodes).
• Arbeitsspeicher erschöpft: Der Linux-Kernel beendet Prozesse (Out-of-Memory-Killer), häufig den Datenbankserver. Hinweis im Log: Out of memory: Killed process ….
• Zu wenige PHP-Prozesse: Bei PHP-FPM begrenzt pm.max_children die parallelen Anfragen. Ist das Limit erreicht, stauen sich Anfragen; Nginx meldet dann upstream timed out und liefert 504 oder 502. Im FPM-Log steht: server reached pm.max_children setting.
• PHP-Speicherlimit: Allowed memory size of 134217728 bytes exhausted führt zu 500 oder einer weißen Seite.
• Hoster-Störung: Netz, Storage oder Virtualisierungshost fallen aus. Hier können Sie nur erkennen, informieren und ggf. auf Ersatz umschalten.

Ein Blick auf die Bedeutung der Gateway-Codes hilft bei der Eingrenzung (siehe HTTP-Statuscodes erklärt): 502 Bad Gateway heißt, der vorgeschaltete Server bekam eine ungültige Antwort der Anwendung, 503 Service Unavailable meldet vorübergehende Überlastung oder Wartung, 504 Gateway Timeout bedeutet, die Anwendung hat nicht rechtzeitig geantwortet (RFC 9110). Alle drei zeigen auf die Schnittstelle zwischen Webserver und Anwendung, nicht auf DNS oder Zertifikat.

Wie verursachen Updates, Deployments und Konfigurationsfehler Ausfälle?

Wenn eine Seite „von einer Minute auf die andere“ kaputt ist, lautet die erste Frage: Was wurde zuletzt geändert? Änderungen sind in der Praxis ein sehr häufiger Auslöser, weil sie den Ist-Zustand verlassen, den man getestet hat. Typische Fälle:

• Plugin- oder Theme-Update in WordPress mit PHP-Fatal-Error; Folge: weiße Seite oder 500. Mehr zu WordPress-spezifischen Fällen: WordPress-Website überwachen.
• Neue PHP-Version beim Hoster, mit der ältere Plugins nicht kompatibel sind.
• Fehler in der .htaccess oder Nginx-Konfiguration: Eine einzige falsche Zeile reicht für einen 500er auf der ganzen Domain. Prüfen Sie Nginx-Konfigurationen vor dem Neuladen mit nginx -t.
• Weiterleitungsschleifen nach einer HTTPS- oder www-Umstellung (Browser: „Zu viele Weiterleitungen“). Siehe Weiterleitungen und Redirect-Ketten.
• Fehlerhafte Migrationen: Datenbankzugang, Dateirechte oder Pfade stimmen nicht mehr (Relaunch und Umzug überwachen).
• Abgelaufene Wartungsseite: Der Wartungsmodus wurde nach dem Update nicht beendet, die Seite liefert dauerhaft 503.

Gegenmaßnahmen sind unspektakulär und wirksam: Änderungen zuerst in einer Testumgebung, vor jeder Änderung ein Backup, Updates außerhalb der Hauptnutzungszeit, ein dokumentierter Rückweg und danach eine Prüfung der wichtigsten Seiten. Ein Monitoring, das die Seite unmittelbar nach dem Update prüft, verkürzt die Zeit bis zur Entdeckung von Stunden auf wenige Minuten; planbare Arbeiten können Sie in ein Wartungsfenster legen, damit sie keine falschen Alarme auslösen.

Warum bricht die Datenbank so oft als erstes weg?

Dynamische Seiten hängen an der Datenbank. Ist sie nicht erreichbar oder überlastet, antwortet die Anwendung mit einem Fehler oder gar nicht. Bei WordPress sehen Besucher dann Error establishing a database connection. Häufige Auslöser:

• Zu viele gleichzeitige Verbindungen: MySQL/MariaDB meldet Too many connections (Fehler 1040), wenn max_connections erreicht ist, etwa bei Lastspitzen, hängenden Prozessen oder zu vielen PHP-Workern.
• Datenbankserver beendet: durch Speichermangel (OOM), volle Platte oder Absturz.
• Langsame Abfragen und Sperren: Eine einzelne teure Abfrage blockiert Tabellen, alle anderen warten, die Seite hängt.
• Beschädigte Tabellen: nach Absturz oder Plattenfehler.
• Geänderte Zugangsdaten: Passwort oder Host wurde geändert, die Konfigurationsdatei nicht.

Wenn die Startseite aus einem Cache bedient wird, bleibt sie bei Datenbankproblemen oft grün, während Suche, Warenkorb und Login ausfallen. Deshalb sollten Sie mindestens eine dynamische Seite oder einen Health-Check-Endpunkt prüfen, der die Datenbank berührt. Ein einfacher Endpunkt in PHP:

<?php
// health.php – liefert 200 nur, wenn die Datenbank antwortet
try {
    $pdo = new PDO('mysql:host=localhost;dbname=shop;charset=utf8mb4', 'user', 'pass',
        [PDO::ATTR_TIMEOUT => 2, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]);
    $pdo->query('SELECT 1');
    header('Content-Type: text/plain'); echo 'OK';
} catch (Throwable $e) {
    http_response_code(503); echo 'DB-Fehler';
}

Sichern Sie den Endpunkt gegen Missbrauch (z. B. kein Detail im Fehlertext), und geben Sie keine Zugangsdaten oder Versionsinformationen aus.

Wie führen DNS-Fehler und abgelaufene Domains zum Totalausfall?

DNS übersetzt den Namen in eine IP-Adresse (RFC 1034, RFC 1035). Fällt das aus, ist Ihr Server zwar gesund, aber niemand findet ihn. Das ist die tückischste Klasse, weil die Fehler oft erst Stunden später sichtbar werden: Resolver halten Antworten im Cache (TTL), also wirkt eine fehlerhafte Änderung verzögert und hält ebenso verzögert an, wenn Sie sie korrigieren.

• Falsche oder gelöschte Einträge: Beim Umzug wurde der A-Eintrag nicht übernommen oder zeigt auf die alte IP.
• Nameserver nicht erreichbar: Der DNS-Anbieter hat eine Störung oder die Delegation ist fehlerhaft. Resolver melden SERVFAIL oder NXDOMAIN.
• DNSSEC-Fehler: Wurde ein DS-Eintrag beim Registrar nicht aktualisiert, scheitert die Validierung; validierende Resolver liefern SERVFAIL, nicht validierende funktionieren weiter. Dadurch ist der Fehler für manche Besucher sichtbar und für andere nicht.
• Domain nicht verlängert: Die Domain wird zum Ablauf gesperrt oder gekündigt; je nach Endung und Registrar zeigt sie auf eine Parkseite oder löst gar nicht mehr auf.
• Registrar-Zahlung gescheitert: Abgelaufene Kreditkarte, andere Rechnungsadresse, E-Mails an eine alte Adresse.

Ein Befehl zum schnellen Test, ob die Autorität antwortet: dig +short NS ihre-domain.de und anschließend dig @ns1.beispiel-dns.de ihre-domain.de A +norecurse. Weitere Diagnose und Überwachung beschreibt DNS-Fehler erkennen und beheben. Wichtig: Tragen Sie das Ablaufdatum Ihrer Domains in einen Kalender ein, der mehr als eine Person sieht.

Warum führen Zertifikate immer noch zu Ausfällen?

Ein abgelaufenes TLS-Zertifikat führt bei modernen Browsern zu einer ganzseitigen Warnung, die die meisten Besucher abbricht. Auch API-Clients, die Zertifikate strikt prüfen, verweigern dann die Verbindung. Dabei wäre der Fehler fast immer vorhersehbar. Typische Wege dorthin:

• Automatische Erneuerung scheitert unbemerkt: Der ACME-Client (RFC 8555, z. B. Certbot) kann die Domain nicht bestätigen, weil eine Weiterleitung, eine Firewall oder eine geänderte Konfiguration die Challenge blockiert. Let’s Encrypt-Zertifikate laufen typischerweise nur 90 Tage; ein stiller Fehler fällt also nach wenigen Wochen auf (siehe die Dokumentation von Let’s Encrypt in den Quellen).
• Zwischenzertifikat fehlt: Manche Clients melden einen Fehler, andere ergänzen die Kette selbst; das erklärt, warum „bei mir geht es“.
• Neuer Server oder neue Subdomain ohne Zertifikat: Das Zertifikat deckt den Namen nicht ab (Hostname-Mismatch).
• Zertifikat nicht neu geladen: Die Datei wurde erneuert, der Webserver läuft aber noch mit dem alten Zertifikat im Speicher, bis zum nächsten Reload.

Prüfen können Sie ein Zertifikat von der Kommandozeile mit:

echo | openssl s_client -connect ihre-domain.de:443 -servername ihre-domain.de 2>/dev/null | openssl x509 -noout -dates -subject

Die Zeile notAfter= nennt das Ablaufdatum. Wie Sie das dauerhaft absichern, zeigt SSL-Zertifikate rechtzeitig prüfen. Die Höchstlaufzeiten öffentlicher Zertifikate werden branchenweit schrittweise verkürzt; Automatisierung und Überwachung gewinnen dadurch an Bedeutung.

Wann werden Traffic-Spitzen und Angriffe zum Problem?

Lastspitzen kommen aus guten Gründen (Werbekampagne, Erwähnung in den Medien, Rabattaktion) und schlechten (Bots, Scraper, Angriffe). Ob die Seite trägt, hängt vom Verhältnis zwischen Kapazität und Last ab. Ein typischer Verlauf: Die Antwortzeiten steigen zuerst, dann erreichen PHP-Prozesse oder Datenbankverbindungen ihr Limit, schließlich antwortet der Server mit 503 oder gar nicht.

• Legitime Spitzen: Vorbereiten mit Seiten-Cache, Objekt-Cache, CDN für statische Dateien und einem Lasttest vor der Aktion.
• Aggressive Crawler und Bots: Rate-Limits, robots.txt für wohlerzogene Bots, Blocklisten bei Missbrauch.
• Verteilte Angriffe (DDoS): Sind in der Regel nur mit vorgelagerten Schutzdiensten beherrschbar; ein einzelner kleiner Server hat keine Chance, Volumenangriffe abzufangen.
• Selbstverursachte Last: Ein neuer Cronjob, ein Import, ein Backup zur Hauptzeit.

Antwortzeiten sind das Frühwarnsignal: Steigen sie über Tage, ist das Kapazitätsproblem schon sichtbar, bevor es zum Ausfall kommt (Antwortzeit interpretieren).

Welche Rolle spielen Drittanbieter?

Moderne Seiten laden Schriften, Skripte, Zahlungsfenster, Kartenmaterial, Consent-Banner und Analyse-Werkzeuge von fremden Servern. Fällt ein solcher Dienst aus, gibt es drei Szenarien: Die Seite funktioniert weiter, nur ohne die Zusatzfunktion (harmlos); die Seite wartet, bis ein Timeout greift (spürbar langsam); oder die Seite wird unbenutzbar, weil ein blockierend geladenes Skript nie zurückkommt. Schlimmer ist der Fall im Shop: Fällt der Zahlungsanbieter aus, kann niemand bezahlen, obwohl die Seite „online“ ist. Eine reine Startseiten-Prüfung sieht das nicht, siehe Onlineshop überwachen.

Prüfen Sie daher, welche externen Dienste kritisch sind, laden Sie unkritische Skripte asynchron (async/defer) und setzen Sie Timeouts, wo Ihre Anwendung serverseitig fremde APIs aufruft. Die Status-Seiten der Anbieter helfen bei der Diagnose, ersetzen aber keine eigene Prüfung.

Welche Prozessfehler führen zu Ausfällen?

Ein erheblicher Teil der „technischen“ Ausfälle hat eine organisatorische Ursache. Beispiele aus dem Alltag:

• Die Hosting-Rechnung geht an eine nicht mehr gelesene Adresse; das Konto wird gesperrt.
• Der Mitarbeiter, der Zugangsdaten und Zertifikate verwaltet, hat das Unternehmen verlassen.
• Beim Aufräumen wird „der alte Server“ gelöscht, auf dem noch ein Subdomain-Dienst lief.
• Eine Änderung am Freitagnachmittag ohne Vertretung für das Wochenende.
• Der Alarm geht an eine Mailbox, die niemand liest, oder an einen Kanal ohne Zuständigen.

Gegenmittel sind Dokumentation (wer ist wofür zuständig, wo liegen Zugänge), Erinnerungen für Fristen und ein Notfallplan, der auch die Frage beantwortet, wer informiert wird und wer entscheidet.

Wie grenzen Sie die Ursache im Ernstfall systematisch ein?

Gehen Sie in der Reihenfolge des Anfragewegs vor. Jede Stufe schließt Ursachen aus. Die Entscheidungsregel lautet: Beim ersten Schritt, der fehlschlägt, liegt die Ursache bei dieser Ebene oder davor.

1. DNS: dig +short ihre-domain.de A – kommt die erwartete IP? Wenn nein: DNS/Domain.
2. Verbindung: curl -sv --connect-timeout 5 https://ihre-domain.de/ -o /dev/null – kommt eine TCP-Verbindung zustande? Wenn nein: Server, Firewall, Hoster-Netz.
3. TLS: Zeigt der Verbose-Output Zertifikatsfehler? Wenn ja: Zertifikat/Kette.
4. HTTP-Status: curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://ihre-domain.de/ – 5xx? Dann Webserver- und Anwendungslogs lesen.
5. Anwendung: Fehlerlog (PHP, Nginx/Apache), letzte Änderungen zurückrollen.
6. Datenbank: Läuft der Dienst? Verbindungen, Plattenplatz, Slow-Query-Log prüfen.
7. Extern: Fremdanbieter-Status prüfen, kritische Skripte testweise deaktivieren.

Prüfen Sie parallel aus einem anderen Netz (zum Beispiel per Mobilfunk), um lokale Störungen auszuschließen. Dokumentieren Sie Uhrzeit, Fehlermeldungen und Gegenmaßnahmen: Sie brauchen sie für den Nachbericht und für die Frage, ob sich die Ursache wiederholen kann.

Welche typischen Fehler verlängern Ausfälle?

• Raten statt Messen: Mehrere Änderungen gleichzeitig, danach weiß niemand, was geholfen hat. Besser: eine Änderung, dann prüfen.
• Cache für gesund halten: Die Startseite kommt aus dem Cache, die Datenbank ist längst weg. Besser: dynamische Prüfziele und Inhaltsprüfung.
• Keine Backups getestet: Ein Backup, das sich nicht einspielen lässt, ist keines. Besser: Wiederherstellung regelmäßig üben.
• Nur ein Kontakt: Alarm geht an eine Person im Urlaub. Besser: Vertretung und zweiten Kanal einrichten (Benachrichtigungen richtig einrichten).
• Ursache nicht nachbereiten: Dieselbe Störung kehrt wieder. Besser: kurze Nachbetrachtung mit konkreter Maßnahme.

Checkliste: Die häufigsten Ausfallursachen vorbeugend prüfen

• Plattenplatz und Inodes mit Warnschwelle (z. B. 80 %) überwacht; Logrotation aktiv.
• PHP-FPM-Prozesse und Datenbankverbindungen zum verfügbaren Speicher passend dimensioniert.
• Updates zuerst in einer Testumgebung, Backup vorher, Rückweg beschrieben.
• Gesundheits-Endpunkt, der die Datenbank berührt, wird überwacht.
• Zertifikate mit Ablaufwarnung überwacht; automatische Erneuerung getestet.
• Domain- und Hostingverlängerung mit Erinnerung an mindestens zwei Personen.
• DNS-Einträge dokumentiert; vor Umstellungen TTL gesenkt.
• Kritische Drittanbieter bekannt; unkritische Skripte asynchron geladen.
• Lasttest vor Kampagnen; Cache- und Rate-Limit-Konzept vorhanden.
• Alarmkanal, Zuständiger, Vertretung und Notfallplan festgelegt.

Grenzen und Einordnung

Keine Maßnahme verhindert alle Ausfälle. Einige Ursachen liegen außerhalb Ihrer Kontrolle: Hoster, Registrar, Zahlungsanbieter, Backbone-Provider. Hier können Sie Wahrscheinlichkeit und Folgen verringern (Redundanz, Alternativen, Kommunikation), aber nicht ausschließen. Auch Überwachung hat Grenzen: Sie erkennt Symptome, nicht automatisch Ursachen, und sie sieht nur, was von außen sichtbar wird (Grenzen automatischer Website-Prüfungen). Zur Frage, was ein Ausfall kostet und wie viel Vorsorge sich dadurch lohnt, lesen Sie Was kostet ein Website-Ausfall?.

Wie setzen Sie die Früherkennung mit UPTIMESHIELD um?

Die meisten oben genannten Klassen lassen sich mit den zehn Monitortypen abdecken: HTTP/HTTPS für Erreichbarkeit und Statuscodes, Keyword und API/JSON für Fehlerseiten mit 200 und den Health-Check-Endpunkt, SSL-Zertifikat mit Warnungen 30, 14, 7, 3 und 1 Tag vor Ablauf, DNS für Auflösung und erwartete Werte, TCP-Port für Dienste wie Mail und Heartbeat für Cronjobs wie Backups. Eine Störung wird standardmäßig nach 2 aufeinanderfolgenden Fehlschlägen bestätigt; Alarme laufen über E-Mail, Webhook, Slack, Microsoft Teams, Telegram oder Discord. Als „langsam“ gilt eine Antwort ab 2.000 ms (einstellbar); das ist oft das erste Zeichen von Ressourcenmangel. Server-interne Werte wie Plattenplatz oder Speicher messen Sie damit nicht; dafür nutzen Sie Werkzeuge auf dem Server selbst. Einen ersten Überblick über Ihre Seite gibt der Sofort-Report ohne Konto, die laufende Überwachung richten Sie nach der kostenlosen Registrierung ein.