Fehler 500, 502, 503: was jeder Code wirklich bedeutet

Wenn eine Website kaputtgeht, ist der Reflex, den Code zu öffnen. Der angezeigte Fehlercode ist der schnellere Hinweis: Er sagt, welche Ebene versagt hat, und die drei häufigsten stehen für drei völlig verschiedene Reparaturen. Fünf Minuten Lektüre hier ersparen eine Stunde Suche an der falschen Stelle.

Die drei Codes, in einer Tabelle

Der 504 steht nicht im Titel und begleitet die anderen doch so oft, dass er seine Zeile verdient: Er ist der einzige der vier, der auf Langsamkeit statt auf Stillstand hinweist.

500: Die Anwendung ist abgestürzt

Der Server läuft und hat geantwortet. Ihr Code ist nicht bis zum Ende gekommen.

Die drei Ursachen, die am häufigsten wiederkehren:

• Ein fataler Fehler nach einem Deployment: eine fehlende Abhängigkeit, eine andere Sprachversion, eine fehlende Konfigurationsdatei.
• Die Datenbank antwortet nicht mehr: Dienst gestoppt, Verbindungen erschöpft, Passwort geändert und nicht verteilt.
• Die Festplatte ist voll. Die am meisten unterschätzte Ursache, weil sie nach nichts aussieht: Sitzungen werden nicht mehr geschrieben, Logs auch nicht, und die Anwendung stolpert über widersprüchliche Fehler.

Wo nachsehen: im Anwendungslog, in der Minute, in der der Fehler auftrat. Ein 500er hinterlässt fast immer eine Spur, mit Datei und Zeilennummer. Wenn dort nichts steht, wurde das Log entweder rotiert oder die Anwendung ist gestorben, bevor sie schreiben konnte, und dann ist das Systemlog die nächste Station.

502: Die Maschine davor hat eine schlechte Antwort bekommen

Ein 502 kommt von einem Proxy: Nginx, ein Load Balancer, ein CDN. Er hat die Anfrage Ihres Besuchers an den dahinterliegenden Server weitergereicht und zurück etwas Unbrauchbares erhalten, oder gar nichts.

Die drei üblichen Ursachen:

• Der Prozess dahinter ist tot oder nie gestartet: PHP-FPM gestoppt, ein abgestürzter Node-Dienst, ein Container, der nach einem Deployment nicht wieder hochkam.
• Der Kommunikationsweg stimmt nicht: ein umbenannter Socket, ein geänderter Port, eine interne Adresse, die bei einem Update verschoben wurde.
• Der Prozess wurde beendet, weil der Speicher ausging. Das Systemlog sagt es, die Anwendung nicht.

Wo nachsehen: der Zustand des Dienstes hinter dem Proxy, vor dem Code. Ein 502 ist die einzige der drei Antworten, die praktisch nie aus Ihrem eigenen Programm stammt, und genau deshalb ist sie so oft falsch zugeordnet.

503: Der Server verweigert, vorübergehend

Ein 503 ist eine absichtliche Antwort: nicht jetzt. Entweder ist die Website im Wartungsmodus, oder dem Server geht die Kapazität aus und er lehnt ab, statt zusammenzubrechen.

Er ist der beruhigendste der drei: Nichts ist kaputt. Er ist auch derjenige, der am längsten dauert, weil er meist auf eine Lastspitze oder eine Warteschlange folgt, die sich nicht leert. Und er ist der einzige, der die richtige Antwort sein kann: Während einer angekündigten Wartung ist ein 503 mit einem Retry-After-Header genau das, was zurückgegeben gehört.

Wo nachsehen: ob ein Wartungsflag aktiv geblieben ist, dann die Last. Ein nach einem Freitags-Deployment vergessener Wartungsmodus ist ein absoluter Klassiker. Prüfen Sie ihn zuerst, bevor Sie irgendetwas über Last vermuten: Er kostet zehn Sekunden und erklärt einen guten Teil aller 503er.

Wo das Log steht, je nach Stack

tail -n 100 /var/log/nginx/error.log        # Nginx, auch 502 und 504
tail -n 100 /var/log/apache2/error.log      # Apache
journalctl -u php8.3-fpm --since "10 min ago"   # PHP-FPM, tote Prozesse
tail -n 100 storage/logs/laravel.log        # die Anwendung, für 500er
df -h && free -m                            # volle Platte, erschöpfter Speicher

Die Reihenfolge zählt: Das Log des Webservers sagt, welche Ebene versagt hat, das Anwendungslog sagt warum. Bei einem 502 mit dem zweiten anzufangen heißt, einen Fehler in einer Datei zu suchen, die nie ausgeführt wurde.

Was beim Hoster zu prüfen ist, bevor Sie den eigenen Code verdächtigen

Drei Dinge, und sie dauern zwei Minuten:

• Die Statusseite des Hosters. Eine Wartung an einer geteilten Datenbank erzeugt bei allen gleichzeitig 500er.
• Die Kontingente. Anzahl der Prozesse, Speicher je Prozess, gleichzeitige Datenbankverbindungen: sie zu überschreiten erzeugt exakt dieselben Symptome wie ein Programmfehler.
• Eine abgelehnte Abbuchung. Ein wegen Zahlungsverzug gesperrter Dienst antwortet oft mit einem 503, und der ursprüngliche Hinweis liegt seit drei Wochen im Spam.

Denken Sie vor allem daran, dass Sie niemand von sich aus warnt: eine grüne Statusseite, während Ihre Website 500er ausliefert, ist aus Sicht des Hosters ein vollkommen normaler Zustand, denn seine Maschine antwortet.

Was Sie dem Kunden währenddessen sagen

Das ist der Absatz, den niemand schreibt und den alle suchen. Zwei Zeilen genügen, und sie nennen keinen Code:

Die Website zeigt seit 14:20 Uhr einen Fehler. Wir wissen, woher er kommt, und arbeiten daran. Ich melde mich um 15 Uhr wieder.

Sagen Sie nicht „Fehler 502“, niemand weiß, was das ist, und es klingt nach Auswendiggelerntem. Versprechen Sie keine Wiederherstellungszeit, solange die Ursache unbekannt ist. Und melden Sie sich, bevor man Sie fragt: Ein Kunde, der den Ausfall selbst entdeckt, behält den Vorfall in Erinnerung, ein informierter Kunde behält die Reaktion.

Die drei Diagnosefehler, die am meisten Zeit kosten

Neu starten, bevor man liest. Ein Neustart löscht meist die Spur dessen, was kaputtging: Der tote Prozess läuft wieder, das Log beginnt von vorn, und der Ausfall kehrt zwei Stunden später zurück, ohne dass Sie mehr wissen. Erst lesen, dann neu starten, in dieser Reihenfolge, wie groß die Versuchung auch sei.

Glauben, der Code nenne den Schuldigen. Er nennt die Ebene, die das Problem gemeldet hat, nicht die, die es verursacht hat. Ein von Nginx gesendeter 502 ist fast immer ein PHP-Problem, und ein 500er der Anwendung ist manchmal eine volle Festplatte, also ein Systemproblem.

Einen Einzelfall für einen Trend halten. Ein einzelner 502 um drei Uhr morgens, während einer Logrotation, verlangt keine Handlung. Drei 502 am selben Tag verlangen eine. Der Unterschied ist nur sichtbar, wenn etwas die Historie aufbewahrt, und genau das ist der echte Mehrwert einer Überwachung gegenüber dem gelegentlichen Blick ins Log.

Was diese Codes nicht sagen

Sie sagen nicht, ob der Besucher die Seite gesehen hat. Wessen Browser die Seite im Cache hatte, hat nichts gemerkt; wer im selben Moment aus einem Suchergebnis kam, sah den Fehler bildschirmfüllend. Sie sagen auch nicht, wie viele Menschen betroffen sind: Ein Fehler, der nur eine bestimmte Route trifft, etwa ein Bestellformular, kann eine lächerliche Zahl von 500ern erzeugen und trotzdem sehr teuer sein.

Was die drei gemeinsam haben

In allen drei Fällen steht die Maschine. Etwas hat geantwortet. Das schließt DNS, Netzwerk und Hosting bereits aus, und genau deshalb lohnt es sich, diesen Code vor allem anderen zu lesen.

Antwortet gar nichts, liegt das Problem woanders, und die ersten fünfzehn Minuten verlaufen anders.

Zwei Nachbarn gehören unterschieden, weil sie oft in diese Familie einsortiert werden. Ein 404 ist kein Ausfall: Es ist die korrekte Antwort auf die Anfrage nach einer Seite, die es nicht gibt, und er wird nach anderen Regeln sortiert. Eine Zertifikatswarnung ist überhaupt kein Fehlercode: Der Server antwortet einwandfrei, der Browser verweigert die Anzeige, und dieser Ausfall hinterlässt in Ihren Logs keine Spur.

Die Frage, die niemand stellt

Welchen Code Sie auch bekommen haben, die nützliche Frage kommt danach: Wie lange wurde er zurückgegeben, bevor Sie davon wussten? Ein 500er, der vier Minuten dauert, ist kein Ereignis. Derselbe 500er, den am nächsten Morgen ein Kunde entdeckt, ist eine andere Geschichte, und der Unterschied hat mit dem Code nichts zu tun.

Es ist auch der einzige Teil, der sich beziffern lässt: was eine Ausfallstunde wirklich kostet hängt viel weniger von der Art des Ausfalls ab als davon, wie lange er auf dem Bildschirm stand.