HTTP-Fehlercodes erklärt: 500, 502, 503, 504 und was sie für deine Kunden bedeuten

Ein weißer Bildschirm mit „500 Internal Server Error" oder „502 Bad Gateway" ist für die meisten Menschen gleichbedeutend mit „kaputt", ohne dass sie wissen, was der Code bedeutet. Für dich als Agentur ist genau dieser dreistellige Code aber eine wertvolle Diagnose-Information: Er verrät, auf welcher Ebene das Problem sitzt und wo du mit der Suche anfangen solltest. Die 5xx-Fehlercodes sind kein zufälliges Kauderwelsch, sondern ein präzises Signalsystem. Dieser Artikel erklärt die vier wichtigsten, 500, 502, 503 und 504, was jeder für deinen Kunden bedeutet, wie du ihn behebst und wie ein Monitoring dich warnt, bevor der erste Kundenanruf kommt.

Kurz vorab: Was die 5xx-Klasse überhaupt bedeutet

HTTP-Statuscodes sind in Klassen organisiert, und die erste Ziffer verrät die Kategorie. Die 2xx-Codes stehen für Erfolg (200 OK), die 3xx für Weiterleitungen, die 4xx für Fehler auf Seiten des Clients: der berühmte 404 („nicht gefunden") gehört hierher, weil der Browser etwas anfragt, das es nicht gibt. Die 5xx-Klasse dagegen signalisiert: Die Anfrage war in Ordnung, aber der Server konnte sie nicht erfüllen. Das Problem liegt auf der Betreiberseite, nicht beim Besucher.

Diese Unterscheidung ist der erste Diagnoseschritt. Ein 5xx-Fehler bedeutet, dass der Besucher nichts falsch gemacht hat und auch nichts tun kann. Die Lösung liegt bei dir. Und die zweite und dritte Ziffer grenzen das Problem weiter ein: Sie sagen, welche Ebene der Server-Infrastruktur klemmt. Genau darin liegt der praktische Wert, den wir jetzt Code für Code aufschlüsseln.

Ein wichtiger Hinweis vorweg: Anders als bei einem DNS-Problem, bei dem die Seite gar nicht erst gefunden wird, ist bei einem 5xx-Fehler der Weg zum Server intakt. Der Server antwortet ja, nur eben mit einem Fehler. Das ist ein anderer Problemtyp und braucht eine andere Suche.

500 Internal Server Error: die Anwendung ist kaputt

Der 500 ist der allgemeinste 5xx-Fehler und zugleich der häufigste. Er ist die Art, wie ein Server sagt: „Ich habe deine Anfrage bekommen, aber beim Bearbeiten ist etwas schiefgelaufen, das ich nicht genauer benennen kann." Der Code selbst ist bewusst unspezifisch. Die eigentliche Ursache steht immer woanders, nämlich im Server- oder Anwendungs-Log.

Was für den Kunden passiert: Die Seite lädt an, die Domain wird gefunden, der Server antwortet, aber statt Inhalt erscheint eine Fehlermeldung. Für den Besucher wirkt es, als sei „die Seite kaputt", obwohl die Infrastruktur drumherum läuft. Bei einem Shop bedeutet das oft: Der Warenkorb oder der Checkout bricht ab, während die Startseite noch normal aussieht.

Typische Ursachen: ein Programmierfehler in der Anwendung, eine fehlgeschlagene oder falsch konfigurierte Datenbankverbindung, ein abgelaufenes Zertifikat für einen internen Dienst, eine fehlerhafte .htaccess oder Server-Konfiguration, oder eine nicht abgefangene Ausnahme im Code, etwa nach einem Deployment.

Wo du mit der Behebung anfängst: immer im Log. Das Anwendungs- und das Server-Log enthalten die konkrete Fehlermeldung, die der 500 verschweigt. Häufig hängt ein 500 mit der letzten Änderung zusammen: ein Deployment, ein Plugin-Update, eine geänderte Konfiguration. Die Frage „was wurde zuletzt angefasst?" führt oft schneller zur Ursache als jede andere.

502 Bad Gateway: falsche Antwort vom Backend

Der 502 führt uns in die Welt der mehrschichtigen Infrastruktur. Moderne Websites laufen selten auf einem einzigen Server; oft steht ein Gateway, ein Reverse Proxy, ein Load Balancer, ein CDN, vor dem eigentlichen Anwendungsserver und reicht Anfragen an ihn weiter. Ein 502 Bad Gateway entsteht, wenn dieses Gateway eine Anfrage weiterleitet, vom Backend aber eine ungültige oder unbrauchbare Antwort zurückbekommt.

Was für den Kunden passiert: Ähnlich wie beim 500 sieht der Besucher eine Fehlerseite statt Inhalt. Der Unterschied ist die Quelle: Nicht die Anwendung selbst meldet den Fehler, sondern der vorgeschaltete Server meldet, dass er mit der Antwort des Backends nichts anfangen kann.

Typische Ursachen: Der Anwendungsserver (etwa ein PHP-FPM-, Node- oder Python-Prozess) ist abgestürzt oder wurde neu gestartet und antwortet gerade nicht sauber. Eine falsch konfigurierte Proxy-Weiterleitung zeigt auf einen Port, an dem nichts (mehr) lauscht. Oder das Backend liefert eine korrupte Antwort, die das Gateway nicht als gültiges HTTP interpretieren kann.

Wo du mit der Behebung anfängst: beim Backend-Dienst hinter dem Gateway. Läuft der Anwendungsprozess überhaupt? Ein Blick, ob der Dienst aktiv ist und auf dem erwarteten Port lauscht, klärt die häufigste Ursache. Danach folgt die Proxy-Konfiguration: Zeigt das Gateway auf die richtige Adresse und den richtigen Port?

503 Service Unavailable: gesund, aber vorübergehend nicht da

Der 503 ist der freundlichste der vier, denn er signalisiert oft kein echtes Versagen, sondern einen bewussten Zustand. „Service Unavailable" heißt: Der Server ist grundsätzlich gesund, kann die Anfrage aber gerade nicht bearbeiten. Meist ist das vorübergehend und manchmal sogar absichtlich.

Was für den Kunden passiert: Die Seite ist kurzzeitig nicht verfügbar. Ein gut gestalteter 503 zeigt eine erklärende Wartungsseite („Wir sind gleich zurück") statt einer nackten Fehlermeldung, und kann im Hintergrund einen Retry-After-Hinweis mitschicken, der Suchmaschinen und Browsern sagt, wann sie es erneut versuchen sollen.

Typische Ursachen: eine laufende Wartung oder ein Deployment, bei dem der Betreiber den Dienst bewusst kurz offline nimmt. Oder eine Überlastung: zu viele gleichzeitige Anfragen, etwa nach einem viralen Post oder einem Angriff, sodass der Server neue Anfragen abweist, statt zusammenzubrechen. Auch ein Dienst, der gerade neu startet und noch nicht bereit ist, liefert oft einen 503.

Wo du mit der Behebung anfängst: zuerst klären, ob der 503 gewollt ist. Läuft eine geplante Wartung, ist alles in Ordnung. Der Code tut genau das Richtige. Ist er ungewollt, deutet er meist auf Kapazität: Reichen die Ressourcen? Gibt es eine Lastspitze? Bei wiederkehrenden 503 unter Last ist Skalierung das Thema, nicht Fehlersuche.

Ein praktischer Punkt für Agenturen: Weil ein 503 sowohl gewollt (Wartung) als auch ungewollt (Überlast) auftreten kann, ist es wichtig, geplante Wartungen im Monitoring als solche zu hinterlegen. Sonst löst die eigene Wartung einen Fehlalarm aus.

504 Gateway Timeout: keine Antwort in der Zeit

Der 504 ist der Zwilling des 502: dieselbe mehrschichtige Konstellation aus Gateway und Backend, aber ein anderer Fehlermodus. Beim 502 kam eine falsche Antwort; beim 504 Gateway Timeout kam gar keine Antwort rechtzeitig. Das Gateway hat die Anfrage ans Backend weitergereicht und dann gewartet, bis eine Zeitgrenze erreicht war und es aufgab.

Was für den Kunden passiert: Die Seite lädt lange und zeigt dann eine Fehlerseite. Das lange Warten davor ist charakteristisch. Anders als beim 502, der oft schnell kommt, ist der 504 das Ergebnis einer abgelaufenen Geduld.

Typische Ursachen: ein Backend, das schlicht zu langsam ist: eine Datenbankabfrage, die sich in einer riesigen Tabelle verrennt, ein externer Dienst (eine Zahlungs-API, ein Drittanbieter), auf den der Server wartet und der selbst hängt, oder ein überlasteter Anwendungsserver, der Anfragen nicht schnell genug abarbeitet. Der gemeinsame Nenner ist immer Zeit: Irgendetwas dauert länger, als das Gateway zu warten bereit ist.

Wo du mit der Behebung anfängst: bei der Performance des Backends. Welche Operation dauert zu lange? Langsame Datenbankabfragen sind der häufigste Verdächtige, gefolgt von externen Aufrufen ohne vernünftiges Timeout. Manchmal ist die Behebung eine Optimierung (ein Index, ein Cache), manchmal ein realistischeres Timeout in der Gateway-Konfiguration, aber die Ursache liegt fast immer in etwas, das zu lange braucht.

Wie Monitoring den Fehler meldet, bevor der Kunde anruft

All dieses Wissen über Fehlercodes hat einen entscheidenden Haken: Es hilft nur, wenn du überhaupt weißt, dass der Fehler auftritt. Und hier liegt das eigentliche Problem im Agentur-Alltag: ein 500 oder 502 auf der Seite eines Kunden erzeugt keinen Anruf bei dir, solange der Kunde es nicht selbst bemerkt. Bis dahin liefert die Seite Besuchern womöglich stundenlang Fehlerseiten aus, ohne dass jemand eingreift.

Genau diese Lücke schließt ein Website-Monitoring. Das Prinzip ist einfach: Ein Monitor ruft die Seite in kurzen Abständen auf, so, wie es ein Besucher täte, und wertet den zurückgegebenen HTTP-Statuscode aus. Kommt ein 200 zurück, ist alles gut. Kommt ein 5xx, 500, 502, 503 oder 504, erkennt der Monitor den Fehler und behandelt ihn als Ausfall. Aus dem stillen Fehler, den nur zufällige Besucher sehen, wird ein aktives Signal, das bei dir ankommt.

Zwei Details machen aus diesem Prinzip ein verlässliches Werkzeug. Erstens die Bestätigung von mehreren Standorten: Bevor ein Alarm ausgelöst wird, prüft Uptimeify den Fehler von mehreren EU-Standorten aus. Ein einzelner, kurzer Ausreißer, ein Server, der sich in einer Sekunde neu startet, löst so keinen Fehlalarm aus; erst ein mehrfach bestätigter 5xx wird zum Incident. Zweitens die Dokumentation mit Zeitstempel: Der erkannte Statuscode wird in der Incident-Historie festgehalten: wann der Fehler begann, welcher Code zurückkam, wie lange er dauerte. Das ist zugleich deine Diagnose-Grundlage (welcher der vier Codes war es?) und dein Beleg gegenüber dem Kunden (wir haben es um 14:03 Uhr erkannt und um 14:15 Uhr behoben).

So schließt sich der Kreis zwischen Wissen und Handeln: Der Fehlercode sagt dir, was los ist und wo du suchen musst. Das Monitoring sagt dir, dass etwas los ist, und zwar bevor dein Kunde es tut.

Vom kryptischen Code zur souveränen Reaktion

Der eigentliche Wert, diese vier Codes zu verstehen, liegt in der Souveränität, die sie dir geben. Wenn der Kunde anruft, oder besser: wenn dein Monitoring dich anpingt, ist der Unterschied zwischen Panik und Kontrolle das Wissen, was der Code bedeutet. „502" ist keine kryptische Botschaft mehr, sondern eine klare Richtungsangabe: Schau beim Backend-Prozess hinter dem Gateway. „504" schickt dich zur Performance, „500" ins Anwendungs-Log, „503" zur Frage nach Wartung oder Last. Jeder Code ist eine Abkürzung zur richtigen Stelle.

Für eine Agentur ist das ein doppelter Gewinn. Nach innen sparst du Diagnosezeit, weil der Code die Suche eingrenzt, statt bei null zu beginnen. Nach außen wirkst du souverän, weil du dem Kunden nicht „irgendwas ist kaputt" erklärst, sondern „das ist ein Gateway-Timeout, das Backend braucht zu lange, wir sind an der Ursache". Diese Präzision ist genau die Professionalität, für die ein Kunde eine Agentur bezahlt.

Und die Grundlage von allem ist, den Fehler früh zu kennen. Ein Fehlercode, den niemand sieht, hilft niemandem. Erst das Monitoring, das ihn bestätigt und meldet, verwandelt das Wissen aus diesem Artikel in eine schnelle, ruhige Reaktion. Wer beides hat, das Verständnis der Codes und ein Monitoring, das sie meldet, macht aus dem gefürchteten weißen Fehlerbildschirm eine beherrschbare Routine.