HTTP-Statuscodes erklärt

Wann immer ein Browser, eine App oder ein Überwachungswerkzeug bei einem Webserver etwas anfragt, beginnt der Server seine Antwort mit einem Statuscode. Das ist eine kurze Zahl, die das Ergebnis zusammenfasst: Es hat geklappt, gehen Sie woandershin, Sie haben etwas falsch gemacht, oder der Server hat etwas falsch gemacht.

Die erste Ziffer gibt die Klasse an, und die Klasse reicht meist, um die Lage zu verstehen.

Die fünf Klassen

„Client-Fehler“ heißt nicht, dass der Besucher schuld ist. Ein defekter Link auf Ihrer eigenen Website erzeugt einen 404, und Ihre Website muss ihn trotzdem beheben.

1xx: Information

Das sind Zwischenantworten. 100 Continue und 101 Switching Protocols sind Beispiele. Gewöhnliche Seitenprüfungen begegnen ihnen fast nie, weil die endgültige Antwort folgt.

2xx: Erfolg

• 200 OK. Die Anfrage war erfolgreich, und die Antwort enthält den Inhalt. Das ist das normale Ergebnis für eine funktionierende Seite.
• 204 No Content. Die Anfrage war erfolgreich, und es gibt nichts zurückzusenden. Häufig bei APIs.

3xx: Weiterleitungen

Eine Weiterleitung weist den Client an, woanders nachzufragen. Die neue Adresse kommt im Location-Header.

• 301 Moved Permanently. Die Adresse hat sich dauerhaft geändert. Browser und Suchmaschinen sollen künftig die neue verwenden. Typischer Einsatz: der Umzug einer Website auf eine neue Domain oder das Erzwingen von https.
• 302 Found. Ein vorübergehender Umzug. Clients sollen künftig weiter die ursprüngliche Adresse verwenden.
• 304 Not Modified. Kein Umzug: Der Inhalt hat sich nicht geändert, der Client kann also seine zwischengespeicherte Kopie verwenden.

Es gibt noch ein weiteres Paar, das man kennen sollte. 308 und 307 verhalten sich wie 301 und 302, garantieren aber, dass Anfragemethode und Inhalt gleich bleiben. Das ist bei Formularen und APIs wichtig.

Jede Weiterleitung kostet einen zusätzlichen Hin- und Rückweg, und eine Kette von Weiterleitungen (A nach B nach C) fügt pro Schritt einen hinzu. Eine Weiterleitungsschleife, bei der das Ziel zurück zum Anfang führt, erreicht nie eine Seite, und Browser brechen irgendwann mit einem Fehler ab.

4xx: Client-Fehler

• 401 Unauthorized. Der Anfrage fehlen gültige Zugangsdaten. Trotz des Namens bedeutet es „nicht authentifiziert“: Melden Sie sich an oder senden Sie gültige Zugangsdaten und versuchen Sie es erneut.
• 403 Forbidden. Der Server hat die Anfrage verstanden und verweigert sie. Der Client ist möglicherweise bekannt, darf aber nicht zugreifen, und eine erneute Anmeldung ändert daran nichts.
• 404 Not Found. Unter dieser Adresse gibt es nichts. Ein Server kann auch 404 zurückgeben, um eine Seite vor Personen zu verbergen, die sie nicht sehen dürfen.
• 429 Too Many Requests. Der Client hat in einer bestimmten Zeit zu viele Anfragen gesendet. Die Antwort kann einen Retry-After-Header enthalten, der sagt, wie lange zu warten ist.

5xx: Server-Fehler

• 500 Internal Server Error. Ein allgemeiner Fehler. Der Server ist auf etwas gestoßen, das er nicht bewältigen konnte, oft ein Bug oder eine Fehlkonfiguration.
• 502 Bad Gateway. Ein Server, der als Gateway oder Proxy arbeitet, hat vom Server dahinter eine ungültige Antwort erhalten.
• 503 Service Unavailable. Der Server kann die Anfrage gerade nicht annehmen, zum Beispiel wegen Wartung oder Überlastung. Der Code ist für vorübergehende Zustände gedacht und kann einen Retry-After-Header enthalten.
• 504 Gateway Timeout. Ein Gateway oder Proxy hat zu lange auf den Server dahinter gewartet.

Beim Lesen von Ausfällen bedeuten 502, 503 und 504 meist ein Problem zwischen den Schichten: Der Proxy davor funktioniert, das Ziel, an das er weiterleitet, nicht.

Warum Statuscodes für die Überwachung wichtig sind

Ein Statuscode ist der schnellste Test, ob eine Website antwortet und richtig antwortet. Er trennt verschiedene Probleme, die für einen Besucher gleich aussehen:

• Gar kein Code (Zeitüberschreitung, abgelehnte Verbindung, DNS-Fehler): Der Server war nicht erreichbar.
• 5xx: Der Server war erreichbar und hat versagt.
• 4xx bei einer Seite, die funktionieren sollte: eine fehlende Seite, ein Berechtigungsproblem oder eine Sperre gegen den Anfragenden.
• 3xx, wo Sie 200 erwartet haben: eine Weiterleitung, die hinzugefügt, entfernt oder beschädigt worden sein kann.

Wer die Codes über die Zeit verfolgt, erkennt auch Muster. Ein einzelner 503 während eines Deployments ist etwas anderes als ein 503 jede Nacht zur selben Stunde.

Weiterleitungen bei der Überwachung

Eine Prüfung, die eine Adresse anfordert, braucht eine Regel für Weiterleitungen. Würde ein 301 als Fehlschlag gewertet, sähe jede Website kaputt aus, die http auf https oder example.com auf www.example.com umleitet. Deshalb folgen die meisten Werkzeuge Weiterleitungen und beurteilen die endgültige Antwort. Die Zahl der Schritte ist begrenzt, damit eine Schleife nicht ewig läuft.

Wie UptimeWire eine Antwort beurteilt

UptimeWire sendet eine GET-Anfrage an die von Ihnen eingerichtete Adresse und folgt Weiterleitungen, höchstens fünf. Dann sieht es sich die endgültige Antwort an:

• 200 bis 399 gilt als erreichbar. Das umfasst 2xx-Erfolgscodes und 3xx-Antworten, bei denen es nicht weitergeht.
• Alles andere ist ein Fehlschlag. Dazu gehören 404, 429, 500, 502, 503 und 504.
• Auch 401 und 403 sind Fehlschläge. Eine überwachte Seite, die ein Login verlangt oder die Anfrage blockiert, wird als fehlgeschlagen gemeldet und nicht als gesund behandelt. Wenn Sie eine Seite hinter einer Anmeldung überwachen, wählen Sie eine öffentliche Adresse wie eine Health-Seite.
• Mehr als fünf Weiterleitungen sind ein Fehlschlag, ebenso keine Antwort, ein Verbindungsfehler, ein DNS-Fehler oder ein ungültiges Zertifikat.

Erfolg auf der Leitung ist keine gesunde Anwendung

Ein 200 bedeutet, dass der Server erfolgreich geantwortet hat. Es bedeutet nicht, dass die Seite korrekt ist. Ein defekter Checkout, der trotzdem eine normale Seite anzeigt, eine leere Seite, wo Daten stehen sollten, oder eine Fehlermeldung im Text einer „200“-Antwort: All das besteht eine HTTP-Prüfung. Was eine solche Prüfung sehen kann und was nicht, steht unter Ausfallzeit. UptimeWire führt keine vollständigen browserbasierten Tests aus. Es prüft die Antwort auf eine Anfrage.

Fehlersuche nach Code

Wenn ein Code auftritt, schauen Sie auch auf die Antwortzeit. Ein Anstieg der Antwortzeit kommt oft kurz bevor 504- oder 503-Fehler beginnen.