{"id":12262,"date":"2020-05-26T09:21:11","date_gmt":"2020-05-26T09:21:11","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2020\/05\/26\/die-10-am-haeufigsten-http-status-codes\/"},"modified":"2026-05-31T20:27:25","modified_gmt":"2026-05-31T20:27:25","slug":"die-10-am-haeufigsten-http-status-codes","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/die-10-am-haeufigsten-http-status-codes\/","title":{"rendered":"Die H\u00e4ufigsten HTTP-Statuscodes (Und Was Man Bei Jedem Tun Sollte)"},"content":{"rendered":"<figure id=\"attachment_33970\" aria-describedby=\"caption-attachment-33970\" style=\"width: 1536px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-33970\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes.webp\" alt=\"Visuelle Referenz der h\u00e4ufigsten HTTP-Statuscodes, gruppiert nach Kategorie\u20142xx Erfolg, 3xx Weiterleitung, 4xx Client-Fehler, 5xx Server-Fehler\" width=\"1536\" height=\"1024\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes.webp 1536w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/hero-http-status-codes-768x512.webp 768w\" sizes=\"(max-width: 1536px) 100vw, 1536px\" \/><figcaption id=\"caption-attachment-33970\" class=\"wp-caption-text\">Die f\u00fcnf Kategorien von HTTP-Statuscodes und die Codes, die Sie tats\u00e4chlich in der Produktion sehen werden.<\/figcaption><\/figure>\n<p>Ihr Pager geht um 2 Uhr morgens los. Die Alarmmeldung enth\u00e4lt einen Statuscode. Was Sie als n\u00e4chstes tun, h\u00e4ngt fast ausschlie\u00dflich davon ab, welchen Code Sie sehen.<\/p>\n<p>Das ist der Teil, den die meisten HTTP-Statuscode-Anleitungen auslassen. Sie listen Definitionen auf, sortieren die Codes in f\u00fcnf Gruppen und h\u00f6ren dann auf. N\u00fctzlich als Glossar, weniger n\u00fctzlich, wenn ein echter Endpunkt 502er wirft und ein Gesch\u00e4ftsf\u00fchrer fragt, warum der Checkout nicht funktioniert.<\/p>\n<p>Dieser Leitfaden behandelt dieselben zehn Codes, die Sie am h\u00e4ufigsten sehen werden, sowie ein paar ehrenwerte Erw\u00e4hnungen. F\u00fcr jeden: was er bedeutet, was ihn normalerweise in der Produktion ausl\u00f6st und was Sie zuerst \u00fcberpr\u00fcfen sollten. Das Ziel ist, die Zeit zwischen \u201eIch sehe den Code\u201c und \u201eIch wei\u00df, was zu beheben ist\u201c zu verk\u00fcrzen.<\/p>\n<h2 id='was-ist-ein-http-statuscode'  id=\"boomdevs_1\">Was ist ein HTTP-Statuscode?<\/h2>\n<p>Ein HTTP-Statuscode ist eine dreistellige Zahl, die der Server mit jeder Antwort zur\u00fccksendet. Er informiert den Client dar\u00fcber, ob die Anfrage erfolgreich war, fehlgeschlagen ist oder umgeleitet werden muss. Sie sehen sie \u00fcberall: im Netzwerk-Tab der DevTools Ihres Browsers, in Load-Balancer-Protokollen, in Monitoring-Alerts, in CDN-Dashboards. Dieser Leitfaden konzentriert sich auf die Codes, die tats\u00e4chlich jemanden aufwecken.<\/p>\n<h2 id='die-f\u00fcnf-kategorien-von-http-statuscodes'  id=\"boomdevs_2\">Die f\u00fcnf Kategorien von HTTP-Statuscodes<\/h2>\n<p>Die erste Ziffer des Codes gibt die Antwortklasse an:<\/p>\n<ul>\n<li><strong>1xx Informativ.<\/strong> Selten im Tagesgesch\u00e4ft. Meistens f\u00fcr Protokollverhandlungen verwendet (100 Continue, 101 Switching Protocols f\u00fcr WebSocket-Upgrades).<\/li>\n<li><strong>2xx Erfolg.<\/strong> Die Anfrage war erfolgreich. 200 ist Standard; 201 bedeutet, dass eine Ressource erstellt wurde; 204 bedeutet Erfolg ohne Inhalt.<\/li>\n<li><strong>3xx Weiterleitung.<\/strong> Die Ressource befindet sich woanders. Browser und Crawler folgen diesen automatisch bis zu einem Limit.<\/li>\n<li><strong>4xx Client-Fehler.<\/strong> Die Anfrage war fehlerhaft. Schlechte URL, fehlende Authentifizierung, gesperrte Berechtigungen, fehlerhafte Nutzlast.<\/li>\n<li><strong>5xx Server-Fehler.<\/strong> Die Anfrage war in Ordnung. Der Server konnte sie nicht erf\u00fcllen.<\/li>\n<\/ul>\n<p>Die Unterscheidung zwischen 4xx und 5xx ist der wichtigste Teil f\u00fcr die Ersteinsch\u00e4tzung. Ein 4xx bedeutet \u201eDer Anrufer hat etwas falsch gemacht\u201c. Ein 5xx bedeutet \u201eWir haben etwas falsch gemacht\u201c. Ersteres geht an den, der den Endpunkt aufgerufen hat. Letzteres geht an Sie.<\/p>\n<p>F\u00fcr eine vollst\u00e4ndige Aufz\u00e4hlung listet das <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/http-status-codes-list\/\">komplette HTTP-Statuscode-Referenz<\/a> im Dotcom-Monitor Wiki jeden im Standard definierten Code auf. Der Rest dieses Leitfadens konzentriert sich auf die, die tats\u00e4chlich in Alerts erscheinen.<\/p>\n<h2 id='die-zehn-h\u00e4ufigsten-http-statuscodes'  id=\"boomdevs_3\">Die zehn h\u00e4ufigsten HTTP-Statuscodes<\/h2>\n<h3 id='200-ok'  id=\"boomdevs_4\">200 OK<\/h3>\n<p>Der Server hat die Anfrage verarbeitet und die erwartete Antwort zur\u00fcckgegeben. Dies ist der Code, den Sie bei der \u00fcberwiegenden Mehrheit der Anfragen an eine gesunde Produktionsseite sehen wollen.<\/p>\n<p><strong>Achten Sie auf:<\/strong> Ein 200 OK ist kein Beweis daf\u00fcr, dass die Seite korrekt ist. JavaScript kann stillschweigend fehlschlagen und eine leere Seite rendern. Eine API kann 200 mit einem Fehlerk\u00f6rper zur\u00fcckgeben. Ein Login-Formular kann \u201eung\u00fcltige Anmeldedaten\u201c in einer 200-Antwort anzeigen. Statuscode-only-Checks \u00fcbersehen das. Kombinieren Sie sie mit echten Browser-Checks (mehr dazu unten).<\/p>\n<h3 id='301-moved-permanently'  id=\"boomdevs_5\">301 Moved Permanently<\/h3>\n<p>Die Ressource hat eine neue permanente URL. Browser cachen die Weiterleitung aggressiv. Suchmaschinen \u00fcbertragen den Gro\u00dfteil der Linkst\u00e4rke auf das Ziel.<\/p>\n<p><strong>Verwenden Sie es f\u00fcr:<\/strong> URL-\u00c4nderungen nach einer Seitenmigration, Wechsel von HTTP zu HTTPS, Konsolidierung doppelter Pfade, Stilllegung alter Slugs. Sobald ein 301 live und gecacht ist, ist ein Zur\u00fcckrollen schmerzhaft \u2013 Browser und Crawler gehen wochenlang zur neuen Adresse.<\/p>\n<h3 id='302-found-temporary-redirect'  id=\"boomdevs_6\">302 Found (Temporary Redirect)<\/h3>\n<p>Die Ressource befindet sich vor\u00fcbergehend woanders. Browser cachen die Weiterleitung nicht, und Suchmaschinen \u00fcbertragen nicht die volle Linkst\u00e4rke.<\/p>\n<p><strong>Achten Sie auf:<\/strong> 302 wird \u00fcberm\u00e4\u00dfig verwendet. Teams greifen darauf zur\u00fcck, weil der Framework-Standard-Redirect-Helfer 302 zur\u00fcckgibt. Wenn der Umzug dauerhaft ist, verwenden Sie 301. Wenn Sie die HTTP-Methode erhalten m\u00fcssen (POST bleibt POST), verwenden Sie stattdessen 307 oder 308. Google behandelt persistente 302s letztlich als 301s, aber \u201eletztlich\u201c ist keine Strategie.<\/p>\n<h3 id='400-bad-request'  id=\"boomdevs_7\">400 Bad Request<\/h3>\n<p>Der Server kann die Anfrage nicht parsen. Fehlerhaftes JSON, ung\u00fcltige Header, zu gro\u00dfe Nutzlasten, Schema-Verst\u00f6\u00dfe.<\/p>\n<p><strong>Pr\u00fcfen Sie zuerst:<\/strong> den Anfragek\u00f6rper. Ein pl\u00f6tzlicher Anstieg von 400 auf einem API-Endpunkt bedeutet meist, dass ein Client angefangen hat, falsche Daten zu senden \u2013 eine \u00c4nderung auf der Verbraucherseite, eine Schema-\u00c4nderung auf Ihrer Seite oder eine Aktualisierung eines Drittanbieter-Formats. Vergleichen Sie die Nutzlast mit der letzten bekannten korrekten Version.<\/p>\n<h3 id='401-unauthorized'  id=\"boomdevs_8\">401 Unauthorized<\/h3>\n<p>Die Anfrage hat keine oder abgelehnte Anmeldedaten. Der Name ist irref\u00fchrend \u2013 das Problem ist die Authentifizierung, nicht die Autorisierung.<\/p>\n<p><strong>Pr\u00fcfen Sie zuerst:<\/strong> Tokens. Ein pl\u00f6tzlicher Anstieg von 401 auf zuvor funktionierenden Endpunkten bedeutet oft, dass ein Token abgelaufen ist, ein Signaturschl\u00fcssel rotiert wurde, ein OIDC-Provider einen Ausfall hatte oder jemand den Audience-Claim ge\u00e4ndert hat. Wenn Ihr <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/ueberwachung-der-api-verfuegbarkeit\/\">API Verf\u00fcgbarkeitsmonitor<\/a> 401 zeigt, wo fr\u00fcher 200 war, ist meist die Authentifizierungsschicht schuld.<\/p>\n<h3 id='403-forbidden'  id=\"boomdevs_9\">403 Forbidden<\/h3>\n<p>Die Anmeldedaten sind g\u00fcltig, aber der Anrufer darf auf diese Ressource nicht zugreifen. Das Problem ist Autorisierung, nicht Authentifizierung.<\/p>\n<p><strong>Pr\u00fcfen Sie zuerst:<\/strong> Berechtigungen und Infrastrukturregeln. 403 erscheinen, wenn eine IAM-Policy ge\u00e4ndert wurde, eine WAF-Regel legitimen Traffic blockiert, eine CDN-Zugriffsregel zu streng ist oder ein Feature-Flag f\u00fcr die falsche Benutzergruppe aktiviert wurde. Wenn 403 direkt nach einem Deploy auftraten, pr\u00fcfen Sie zuerst Policy- und Konfigurations\u00e4nderungen, bevor Sie den Anwendungs-Code betrachten.<\/p>\n<h3 id='404-not-found'  id=\"boomdevs_10\">404 Not Found<\/h3>\n<p>Der Server hat die Anfrage verstanden, findet aber keine Ressource unter dieser URL. Der bekannteste Statuscode \u00fcberhaupt.<\/p>\n<p><strong>Zwei F\u00e4lle zu unterscheiden:<\/strong><\/p>\n<ul>\n<li><strong>Einzelne 404s<\/strong> durch Tippfehler, alte Lesezeichen oder Crawler, die nach Sicherheitsl\u00fccken suchen. Diese sind Hintergrundrauschen.<\/li>\n<li><strong>Ein Anstieg von 404s auf kanonischen URLs<\/strong> direkt nach einem Deploy. Das ist ein fehlerhaftes Release \u2013 Routen fehlen, ein Build-Artefakt ist verloren, oder jemand hat eine Slug-\u00c4nderung ohne Weiterleitungen ver\u00f6ffentlicht. Rollback oder Hotfix ansto\u00dfen.<\/li>\n<\/ul>\n<p>Persistente 404 auf indexierten Seiten werden von Google irgendwann rausgekickt, daher kosten kanonische Seiten mit 404 auch SEO-Ranking.<\/p>\n<h4 id='behebung'  id=\"boomdevs_11\">Behebung<\/h4>\n<p><strong>Schneller Weg:<\/strong> Wenn die Seite verschoben wurde, f\u00fcgen Sie einen 301-Redirect von der alten URL zur neuen hinzu, damit Benutzer und Crawler an der richtigen Stelle landen. Wenn die Seite wirklich weg ist, geben Sie einen echten 404 oder 410 zur\u00fcck anstelle eines unklaren Redirects auf die Startseite.<\/p>\n<p><strong>Wirkliche L\u00f6sung:<\/strong> \u00dcberpr\u00fcfen Sie die Quelle der 404. Interne defekte Links werden an der Quelle korrigiert; fehlende Routen nach Deploy erhalten einen Hotfix; eine fehlerhafte Migration, die Slugs verloren hat, braucht eine Redirect-Map. Crawlen Sie Ihre eigene Seite regelm\u00e4\u00dfig, um tote Links vor Google zu finden.<\/p>\n<h3 id='500-internal-server-error'  id=\"boomdevs_12\">500 Internal Server Error<\/h3>\n<p>Der Server hatte eine unbehandelte Ausnahme. Der Allzweck-5xx-Code. Er sagt, dass etwas kaputt ist, aber nicht was.<\/p>\n<p><strong>Pr\u00fcfen Sie zuerst:<\/strong> Anwendungsprotokolle. Jeder 500 hat irgendwo einen Stacktrace \u2013 wenn nicht, muss Ihr Logging verbessert werden, bevor Sie den Code debuggen. H\u00e4ufige Ursachen: Eine ungefangene Ausnahme in einem k\u00fcrzlich ausgerollten Codepfad, eine Abh\u00e4ngigkeit liefert unerwartete Daten, Verbindungs-Pool zur Datenbank ersch\u00f6pft, ein Out-of-Memory-Restart-Loop. Ein andauernder 500-Anstieg an einem Produktions-Endpunkt sollte den Bereitschaftsdienst ausl\u00f6sen.<\/p>\n<h4 id='behebung-1'  id=\"boomdevs_13\">Behebung<\/h4>\n<p><strong>Schneller Weg:<\/strong> Wenn der Anstieg direkt nach einem Release startete, rollen Sie zur\u00fcck. Ein 500, das kurz nach einem Deploy erscheint, ist das Deploy bis zum Beweis des Gegenteils.<\/p>\n<p><strong>Wirkliche L\u00f6sung:<\/strong> Lesen Sie den Stacktrace und patchen Sie den fehlerhaften Codepfad, dann f\u00fcgen Sie einen Regressionstest hinzu, damit das Problem nicht zur\u00fcckkehrt. War die Ursache eine Ressourcenbegrenzung \u2013 Verbindungs-Pool, Speicher, Dateihandles \u2013 erh\u00f6hen Sie das Limit und f\u00fcgen Sie eine Warnung hinzu, bevor Sie es das n\u00e4chste Mal erreichen.<\/p>\n<h3 id='502-bad-gateway'  id=\"boomdevs_14\">502 Bad Gateway<\/h3>\n<p>Ein Proxy, Load-Balancer oder CDN erhielt eine ung\u00fcltige Antwort vom Upstream-Server. Der Proxy selbst ist gesund. Der dahinterliegende Server nicht.<\/p>\n<p><strong>Pr\u00fcfen Sie zuerst:<\/strong> Den Gesundheitsstatus des Upstreams. H\u00e4ufige Ursachen: Ein App-Container ist abgest\u00fcrzt, aber der Load-Balancer sendet immer noch Traffic dorthin, der Upstream antwortet nicht rechtzeitig, ein Kubernetes-Pod steckt in CrashLoopBackOff, ein Nginx-Worker ist falsch konfiguriert, oder die Verbindung zwischen Proxy und Upstream wurde zur\u00fcckgesetzt. 502 ist einer der aussagekr\u00e4ftigsten Codes bei Schichtenarchitekturen \u2013 er sagt, dass der Edge in Ordnung ist und das Problem eine Schicht weiter hinten liegt.<\/p>\n<h4 id='behebung-2'  id=\"boomdevs_15\">Behebung<\/h4>\n<p><strong>Schneller Weg:<\/strong> Starten oder ersetzen Sie die ungesunde Upstream-Instanz neu und vergewissern Sie sich, dass die Health-Checks des Load-Balancers tote Knoten tats\u00e4chlich aus dem Verkehr ziehen.<\/p>\n<p><strong>Wirkliche L\u00f6sung:<\/strong> Finden Sie heraus, warum der Upstream M\u00fcll zur\u00fcckgegeben hat. Pr\u00fcfen Sie, ob das Timeout des Proxys k\u00fcrzer ist als die tats\u00e4chliche Antwortzeit des Upstreams, ob der Pod beim Start in einer Crash-Schleife steckt und ob die Keep-Alive-Einstellungen auf beiden Seiten der Verbindung \u00fcbereinstimmen.<\/p>\n<h3 id='503-service-unavailable'  id=\"boomdevs_16\">503 Service Unavailable<\/h3>\n<p>Der Server ist vor\u00fcbergehend nicht in der Lage, die Anfrage zu bearbeiten. Kapazit\u00e4t ersch\u00f6pft, Wartungsmodus, Autoscaler ist noch am Hochfahren.<\/p>\n<p><strong>Pr\u00fcfen Sie zuerst:<\/strong> Ressourcenauslastung und Rate-Limits. 503 w\u00e4hrend eines Traffic-Spikes bedeuten meist, dass der Autoscaler nicht nachkommt oder Sie eine Verbindungsgrenze erreicht haben. 503 im stabilen Zustand zeigen meist Wartungsprozesse oder R\u00fcckstau in einer Warteschlange. Manche Plattformen geben 503 auch zur\u00fcck, wenn ein WAF- oder Anti-Bot-System den Anrufer limitiert \u2013 pr\u00fcfen, bevor Sie annehmen, dass die App das Problem ist.<\/p>\n<h4 id='behebung-3'  id=\"boomdevs_17\">Behebung<\/h4>\n<p><strong>Schneller Weg:<\/strong> Geben Sie 503 mit einem <code>Retry-After<\/code>-Header zur\u00fcck, damit gut erzogene Clients und Crawler Abstand halten statt den angeschlagenen Server zu bombardieren. In PHP:<\/p>\n<pre><code>http_response_code(503);\nheader('Retry-After: 60');<\/code><\/pre>\n<p><strong>Wirkliche L\u00f6sung:<\/strong> Finden Sie die ausgelastete Ressource \u2013 Datenbankverbindungen, Worker-Pool, Autoscaler-Limit \u2013 und beseitigen Sie den Engpass. Kam die 503 von einem Rate-Limit eines CDN oder WAF, erh\u00f6hen Sie das Limit oder setzen Sie den legitimen Anrufer auf die Whitelist.<\/p>\n<h2 id='weitere-wichtige-codes'  id=\"boomdevs_18\">Weitere wichtige Codes<\/h2>\n<p>Die oben genannten zehn decken den Gro\u00dfteil des Produktions-Traffics ab. Aber ein paar andere Codes kommen oft genug bei echten Vorf\u00e4llen vor, dass On-Call-Ingenieure sie auf Anhieb kennen sollten.<\/p>\n<ul>\n<li><strong>304 Not Modified.<\/strong> Gesendet, wenn eine gecachte Ressource noch aktuell ist. H\u00e4ufig bei CDN-gest\u00fctztem Traffic. Ein R\u00fcckgang von 304 kann bedeuten, dass sich Ihre Cache-Control-Header ge\u00e4ndert haben und Sie wieder Origin-Bandbreite zahlen statt zu sparen.<\/li>\n<li><strong>307 Temporary Redirect.<\/strong> Wie 302, aber die HTTP-Methode bleibt erhalten. Ein POST bleibt ein POST. Verwenden Sie 307 statt 302 bei Weiterleitungen von Formularen oder nicht-idempotenten API-Aufrufen.<\/li>\n<li><strong>308 Permanent Redirect.<\/strong> Wie 301, aber die HTTP-Methode bleibt erhalten. Die moderne Wahl bei dauerhaften Weiterleitungen von API-Endpunkten mit POST, PUT, PATCH oder DELETE.<\/li>\n<li><strong>429 Too Many Requests.<\/strong> Rate-Limit erreicht. Entweder werden Sie von einer Upstream-API gedrosselt oder Sie drosseln jemanden selbst. Pr\u00fcfen Sie <code>Retry-After<\/code>-Header; respektieren Sie diese.<\/li>\n<li><strong>504 Gateway Timeout.<\/strong> Ein Proxy hat das Warten auf den Upstream aufgegeben. Anders als 502 hat der Upstream keine schlechte Antwort geliefert, sondern keine Antwort rechtzeitig. Meist eine lang laufende Abfrage, ein eingefrorener Worker oder eine langsame Downstream-API.<\/li>\n<\/ul>\n<h3 id='301-vs-302-vs-307-vs-308'  id=\"boomdevs_19\">301 vs 302 vs 307 vs 308<\/h3>\n<p>Die vier Redirect-Codes werden st\u00e4ndig verwechselt. Der Unterschied beruht auf zwei Dingen: ob die Weiterleitung dauerhaft ist und ob die HTTP-Methode erhalten bleibt.<\/p>\n<div class=\"table-wrap\">\n<table class=\"compare\">\n<thead>\n<tr>\n<th>Verhalten<\/th>\n<th>301<\/th>\n<th>302<\/th>\n<th>307<\/th>\n<th>308<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Dauer<\/td>\n<td>Dauerhaft<\/td>\n<td>Vor\u00fcbergehend<\/td>\n<td>Vor\u00fcbergehend<\/td>\n<td>Dauerhaft<\/td>\n<\/tr>\n<tr>\n<td>Methode erhalten<\/td>\n<td>Nicht garantiert<\/td>\n<td>Nicht garantiert<\/td>\n<td>Ja<\/td>\n<td>Ja<\/td>\n<\/tr>\n<tr>\n<td>Browser-Cache<\/td>\n<td>Aggressiv<\/td>\n<td>Nein<\/td>\n<td>Nein<\/td>\n<td>Ja<\/td>\n<\/tr>\n<tr>\n<td>Linkst\u00e4rke \u00fcbertragen<\/td>\n<td>Gro\u00dftenteils<\/td>\n<td>Begrenzt<\/td>\n<td>Begrenzt<\/td>\n<td>Gro\u00dftenteils<\/td>\n<\/tr>\n<tr>\n<td>Verwendung<\/td>\n<td>Dauerhafte URL-\u00c4nderung<\/td>\n<td>Kurzfristige \u00c4nderung<\/td>\n<td>Formular- oder POST-Redirect<\/td>\n<td>Dauerhafte API-Endpunkt-\u00c4nderung<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>F\u00fcr eine einfache Seite, die dauerhaft verschoben wurde, verwenden Sie 301. Wenn die Weiterleitung eine POST-Anfrage als POST erhalten muss \u2013 bei Formularen oder nicht-idempotenten API-Anrufen \u2013 verwenden Sie 307 bei vor\u00fcbergehender und 308 bei dauerhafter Umleitung.<\/p>\n<h2 id='die-vollst\u00e4ndige-http-statuscode-referenz'  id=\"boomdevs_20\">Die vollst\u00e4ndige HTTP-Statuscode-Referenz<\/h2>\n<p>Die obigen Codes decken fast alles ab, was einen echten Alarm ausl\u00f6st. F\u00fcr ungew\u00f6hnliche Codes \u2013 die einmal pro Quartal auftauchen und Sie etwas nachschlagen lassen \u2013 hier die komplette Standardliste plus nicht standardisierte Codes von g\u00e4ngigen Infrastruktur-Anbietern.<\/p>\n<h3 id='1xx-informativ'  id=\"boomdevs_21\">1xx Informativ<\/h3>\n<p>Der Server hat die Anfrage erhalten und verarbeitet sie weiter. Diese sieht man selten in Anwendungsprotokollen, da die meisten Clients und Proxys sie transparent behandeln.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Code<\/th>\n<th>Bedeutung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>100<\/td>\n<td>Continue<\/td>\n<\/tr>\n<tr>\n<td>101<\/td>\n<td>Switching Protocols<\/td>\n<\/tr>\n<tr>\n<td>102<\/td>\n<td>Processing<\/td>\n<\/tr>\n<tr>\n<td>103<\/td>\n<td>Early Hints<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='2xx-erfolg'  id=\"boomdevs_22\">2xx Erfolg<\/h3>\n<p>Die Anfrage wurde empfangen, verstanden und akzeptiert. 200 ist der Arbeitstier-Code; die anderen sind wichtig, wenn Sie APIs bauen oder mit Teilinhalten, WebDAV oder Batch-Operationen arbeiten.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Code<\/th>\n<th>Bedeutung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>200<\/td>\n<td>OK<\/td>\n<\/tr>\n<tr>\n<td>201<\/td>\n<td>Created<\/td>\n<\/tr>\n<tr>\n<td>202<\/td>\n<td>Accepted<\/td>\n<\/tr>\n<tr>\n<td>203<\/td>\n<td>Non-Authoritative Information<\/td>\n<\/tr>\n<tr>\n<td>204<\/td>\n<td>No Content<\/td>\n<\/tr>\n<tr>\n<td>205<\/td>\n<td>Reset Content<\/td>\n<\/tr>\n<tr>\n<td>206<\/td>\n<td>Partial Content<\/td>\n<\/tr>\n<tr>\n<td>207<\/td>\n<td>Multi-Status<\/td>\n<\/tr>\n<tr>\n<td>208<\/td>\n<td>Already Reported<\/td>\n<\/tr>\n<tr>\n<td>226<\/td>\n<td>IM Used<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='3xx-weiterleitung'  id=\"boomdevs_23\">3xx Weiterleitung<\/h3>\n<p>Die Ressource befindet sich woanders, oder die gecachte Kopie ist noch g\u00fcltig. 301 und 302 dominieren; die anderen sind wichtig f\u00fcr APIs (307\/308 erhalten die HTTP-Methode) und Caching-Pipelines (304 spart Origin-Bandbreite).<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Code<\/th>\n<th>Bedeutung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>300<\/td>\n<td>Multiple Choices<\/td>\n<\/tr>\n<tr>\n<td>301<\/td>\n<td>Moved Permanently<\/td>\n<\/tr>\n<tr>\n<td>302<\/td>\n<td>Found<\/td>\n<\/tr>\n<tr>\n<td>303<\/td>\n<td>See Other<\/td>\n<\/tr>\n<tr>\n<td>304<\/td>\n<td>Not Modified<\/td>\n<\/tr>\n<tr>\n<td>305<\/td>\n<td>Use Proxy (deprecated)<\/td>\n<\/tr>\n<tr>\n<td>306<\/td>\n<td>Switch Proxy (unused)<\/td>\n<\/tr>\n<tr>\n<td>307<\/td>\n<td>Temporary Redirect<\/td>\n<\/tr>\n<tr>\n<td>308<\/td>\n<td>Permanent Redirect<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='4xx-client-fehler'  id=\"boomdevs_24\">4xx Client-Fehler<\/h3>\n<p>Die Anfrage war fehlerhaft. Die meisten davon sehen Sie nie; die eine Handvoll h\u00e4ufigerer kommen t\u00e4glich vor. Es lohnt sich, die seltenen zu kennen, damit Sie keine Zeit verschwenden, wenn ein 418 oder 451 in einem Log auftaucht.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Code<\/th>\n<th>Bedeutung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>400<\/td>\n<td>Bad Request<\/td>\n<\/tr>\n<tr>\n<td>401<\/td>\n<td>Unauthorized<\/td>\n<\/tr>\n<tr>\n<td>402<\/td>\n<td>Payment Required<\/td>\n<\/tr>\n<tr>\n<td>403<\/td>\n<td>Forbidden<\/td>\n<\/tr>\n<tr>\n<td>404<\/td>\n<td>Not Found<\/td>\n<\/tr>\n<tr>\n<td>405<\/td>\n<td>Method Not Allowed<\/td>\n<\/tr>\n<tr>\n<td>406<\/td>\n<td>Not Acceptable<\/td>\n<\/tr>\n<tr>\n<td>407<\/td>\n<td>Proxy Authentication Required<\/td>\n<\/tr>\n<tr>\n<td>408<\/td>\n<td>Request Timeout<\/td>\n<\/tr>\n<tr>\n<td>409<\/td>\n<td>Conflict<\/td>\n<\/tr>\n<tr>\n<td>410<\/td>\n<td>Gone<\/td>\n<\/tr>\n<tr>\n<td>411<\/td>\n<td>Length Required<\/td>\n<\/tr>\n<tr>\n<td>412<\/td>\n<td>Precondition Failed<\/td>\n<\/tr>\n<tr>\n<td>413<\/td>\n<td>Payload Too Large<\/td>\n<\/tr>\n<tr>\n<td>414<\/td>\n<td>URI Too Long<\/td>\n<\/tr>\n<tr>\n<td>415<\/td>\n<td>Unsupported Media Type<\/td>\n<\/tr>\n<tr>\n<td>416<\/td>\n<td>Range Not Satisfiable<\/td>\n<\/tr>\n<tr>\n<td>417<\/td>\n<td>Expectation Failed<\/td>\n<\/tr>\n<tr>\n<td>418<\/td>\n<td>I&#8217;m a teapot<\/td>\n<\/tr>\n<tr>\n<td>421<\/td>\n<td>Misdirected Request<\/td>\n<\/tr>\n<tr>\n<td>422<\/td>\n<td>Unprocessable Content<\/td>\n<\/tr>\n<tr>\n<td>423<\/td>\n<td>Locked<\/td>\n<\/tr>\n<tr>\n<td>424<\/td>\n<td>Failed Dependency<\/td>\n<\/tr>\n<tr>\n<td>425<\/td>\n<td>Too Early<\/td>\n<\/tr>\n<tr>\n<td>426<\/td>\n<td>Upgrade Required<\/td>\n<\/tr>\n<tr>\n<td>428<\/td>\n<td>Precondition Required<\/td>\n<\/tr>\n<tr>\n<td>429<\/td>\n<td>Too Many Requests<\/td>\n<\/tr>\n<tr>\n<td>431<\/td>\n<td>Request Header Fields Too Large<\/td>\n<\/tr>\n<tr>\n<td>451<\/td>\n<td>Unavailable For Legal Reasons<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='5xx-server-fehler'  id=\"boomdevs_25\">5xx Server-Fehler<\/h3>\n<p>Die Anfrage war in Ordnung. Etwas auf der Serverseite ist fehlgeschlagen. Diese Codes wecken meistens jemanden auf.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Code<\/th>\n<th>Bedeutung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>500<\/td>\n<td>Internal Server Error<\/td>\n<\/tr>\n<tr>\n<td>501<\/td>\n<td>Not Implemented<\/td>\n<\/tr>\n<tr>\n<td>502<\/td>\n<td>Bad Gateway<\/td>\n<\/tr>\n<tr>\n<td>503<\/td>\n<td>Service Unavailable<\/td>\n<\/tr>\n<tr>\n<td>504<\/td>\n<td>Gateway Timeout<\/td>\n<\/tr>\n<tr>\n<td>505<\/td>\n<td>HTTP Version Not Supported<\/td>\n<\/tr>\n<tr>\n<td>506<\/td>\n<td>Variant Also Negotiates<\/td>\n<\/tr>\n<tr>\n<td>507<\/td>\n<td>Insufficient Storage<\/td>\n<\/tr>\n<tr>\n<td>508<\/td>\n<td>Loop Detected<\/td>\n<\/tr>\n<tr>\n<td>510<\/td>\n<td>Not Extended<\/td>\n<\/tr>\n<tr>\n<td>511<\/td>\n<td>Network Authentication Required<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='nicht-standardisierte-und-vendor-codes'  id=\"boomdevs_26\">Nicht standardisierte und Vendor-Codes<\/h3>\n<p>Cloudflare, Nginx, Microsoft und Akamai geben alle Codes au\u00dferhalb der offiziellen Spezifikation zur\u00fcck, wenn ihre Infrastrukturschicht ausf\u00e4llt. Diese sollten Sie auf Anhieb erkennen, weil sie anzeigen, dass der Fehler am Edge liegt, nicht am Origin.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Code<\/th>\n<th>Bedeutung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>419<\/td>\n<td>Authentication Timeout<\/td>\n<\/tr>\n<tr>\n<td>420<\/td>\n<td>Enhance Your Calm \/ Method Failure<\/td>\n<\/tr>\n<tr>\n<td>440<\/td>\n<td>Login Timeout (Microsoft)<\/td>\n<\/tr>\n<tr>\n<td>444<\/td>\n<td>No Response (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>449<\/td>\n<td>Retry With (Microsoft)<\/td>\n<\/tr>\n<tr>\n<td>450<\/td>\n<td>Blocked by Windows Parental Controls<\/td>\n<\/tr>\n<tr>\n<td>460<\/td>\n<td>Client Closed Connection<\/td>\n<\/tr>\n<tr>\n<td>494<\/td>\n<td>Request Header Too Large (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>495<\/td>\n<td>SSL Certificate Error (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>496<\/td>\n<td>SSL Certificate Required (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>497<\/td>\n<td>HTTP Request Sent to HTTPS Port<\/td>\n<\/tr>\n<tr>\n<td>498<\/td>\n<td>Invalid Token<\/td>\n<\/tr>\n<tr>\n<td>499<\/td>\n<td>Client Closed Request (Nginx)<\/td>\n<\/tr>\n<tr>\n<td>509<\/td>\n<td>Bandwidth Limit Exceeded<\/td>\n<\/tr>\n<tr>\n<td>520<\/td>\n<td>Unknown Error (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>521<\/td>\n<td>Web Server Is Down (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>522<\/td>\n<td>Connection Timed Out (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>523<\/td>\n<td>Origin Is Unreachable (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>524<\/td>\n<td>A Timeout Occurred (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>525<\/td>\n<td>SSL Handshake Failed (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>526<\/td>\n<td>Invalid SSL Certificate (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>527<\/td>\n<td>Railgun Error (Cloudflare)<\/td>\n<\/tr>\n<tr>\n<td>529<\/td>\n<td>Site Overloaded<\/td>\n<\/tr>\n<tr>\n<td>530<\/td>\n<td>Site Frozen \/ Origin DNS Error<\/td>\n<\/tr>\n<tr>\n<td>561<\/td>\n<td>Unauthorized (Akamai)<\/td>\n<\/tr>\n<tr>\n<td>598<\/td>\n<td>Network Read Timeout<\/td>\n<\/tr>\n<tr>\n<td>599<\/td>\n<td>Network Connect Timeout<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Code-Bereiche, die oben nicht gelistet sind (104-199, 209-225, 227-299, 309-399, 432-450, 452-499, 512-599), sind entweder nicht zugewiesen, veraltet oder f\u00fcr Vendor-Codes reserviert. Behandeln Sie Codes in diesen Bereichen als herstellerspezifisch und lesen Sie die Infrastruktur-Dokumentation.<\/p>\n<h3 id='die-codes-auf-die-ihre-\u00fcberwachung-tats\u00e4chlich-alarmieren-sollte'  id=\"boomdevs_27\">Die Codes, auf die Ihre \u00dcberwachung tats\u00e4chlich alarmieren sollte<\/h3>\n<p>Von den \u00fcber 60 Codes oben ist die Liste derjenigen, die in den meisten Produktionsumgebungen Alarme ausl\u00f6sen, deutlich k\u00fcrzer:<\/p>\n<ul>\n<li><strong>200<\/strong> \u2013 als Grundlinie. Ein pl\u00f6tzlicher R\u00fcckgang bedeutet, dass etwas anderes schief l\u00e4uft.<\/li>\n<li><strong>301, 302, 307, 308<\/strong> \u2013 Anzahl der Weiterleitungen. Anstiege k\u00f6nnen auf Fehlkonfigurationen oder Deployments hinweisen, die kanonische URLs brechen.<\/li>\n<li><strong>400<\/strong> \u2013 fehlerhafte Anfragen. Meist \u00c4nderungen auf der Verbraucherseite.<\/li>\n<li><strong>401, 403<\/strong> \u2013 Authentifizierungs- und Berechtigungsfehler. Oft Token-, IAM- oder WAF-\u00c4nderungen.<\/li>\n<li><strong>404<\/strong> \u2013 fehlende Ressourcen. Einzelne Fehler sind Hintergrundrauschen; geh\u00e4uftes Auftreten ein Release-Problem.<\/li>\n<li><strong>408<\/strong> \u2013 Client-Timeouts. Bei anhaltender Rate alarmieren; deuten auf langsame Downstream-Aufrufe.<\/li>\n<li><strong>429<\/strong> \u2013 Rate-Limits. Entweder Sie werden limitiert oder drosseln selbst zu stark.<\/li>\n<li><strong>500, 502, 503, 504<\/strong> \u2013 Fehler in Anwendung, Upstream, Kapazit\u00e4t und Gateway-Timeout. Diese l\u00f6sen Paging aus.<\/li>\n<li><strong>520-526<\/strong> \u2013 Edge-Fehler bei Cloudflare. Wenn Sie hinter Cloudflare sind, sind diese kritische Signale, da sie den Fehler auf den Edge-Origin-Pfad eingrenzen.<\/li>\n<\/ul>\n<p>Alles andere ist es wert, protokolliert zu werden, aber selten so wichtig, dass jemand geweckt werden muss.<\/p>\n<h2 id='wie-man-den-http-statuscode-einer-seite-pr\u00fcft'  id=\"boomdevs_28\">Wie man den HTTP-Statuscode einer Seite pr\u00fcft<\/h2>\n<p>Bevor Sie auf einen Code reagieren, m\u00fcssen Sie ihn sehen. Drei Methoden, von der schnellsten bis zur gr\u00fcndlichsten.<\/p>\n<h3 id='in-chrome-devtools'  id=\"boomdevs_29\">In Chrome DevTools<\/h3>\n<ol>\n<li>\u00d6ffnen Sie die Seite.<\/li>\n<li>Rechtsklick irgendwo und \u201eUntersuchen\u201c w\u00e4hlen, dann den Netzwerk-Tab \u00f6ffnen.<\/li>\n<li>Seite neu laden. Die erste Dokument-Anfrage zeigt den Code in der Spalte \u201eStatus\u201c.<\/li>\n<\/ol>\n<h3 id='\u00fcber-die-kommandozeile'  id=\"boomdevs_30\">\u00dcber die Kommandozeile<\/h3>\n<p>Eine reine Header-Anfrage gibt die Statuszeile zur\u00fcck, ohne den Body herunterzuladen:<\/p>\n<pre><code>curl -I https:\/\/example.com<\/code><\/pre>\n<p>Die erste Zeile der Antwort ist der Statuscode \u2013 zum Beispiel <code>HTTP\/2 200<\/code>.<\/p>\n<h3 id='im-gro\u00dfen-ma\u00dfstab'  id=\"boomdevs_31\">Im gro\u00dfen Ma\u00dfstab<\/h3>\n<p>Einmalige Checks zeigen den aktuellen Zustand. Sie erfassen aber nicht den Fehler, der um 3 Uhr morgens passiert und verschwindet, bevor Sie aufwachen. Um intermittierende Fehler zu erfassen, brauchen Sie geplante Checks von mehreren Regionen \u2013 wie <a href=\"https:\/\/www.dotcom-monitor.com\/de\/loesungen\/synthetic-monitoring\/\">synthetisches Monitoring<\/a> es leistet.<\/p>\n<h2 id='wenn-ein-200-ok-l\u00fcgt'  id=\"boomdevs_32\">Wenn ein 200 OK l\u00fcgt<\/h2>\n<p>Ein E-Commerce-Team bekommt am Dienstag um 11 Uhr eine Pager-Alarmierung. Die Conversion ist um 80 Prozent eingebrochen. Sie pr\u00fcfen ihr Uptime-Dashboard. Alle Endpunkte sind gr\u00fcn. Alle Statuscodes 200. Alle Regionen melden die Seite als erreichbar.<\/p>\n<p>Die Seite ist nicht erreichbar. Ein Deploy 40 Minuten zuvor hat ein JavaScript-B\u00fcndel ausgeliefert, das auf der Checkout-Seite Fehler wirft. Das HTML rendert, der Server gibt 200 zur\u00fcck, der Status-Code-Monitor erkennt 200, kein Alarm wird ausgel\u00f6st. Nutzer sehen einen leeren Warenkorb und springen ab.<\/p>\n<p>Das ist der Fehlerfall, den reines Statuscode-Monitoring nicht erkennen kann. Die L\u00f6sung ist vielschichtig:<\/p>\n<ul>\n<li><strong>F\u00fchren Sie echte Browser-Checks durch<\/strong> auf kritischen Nutzerpfaden \u2013 Startseite, Suche, Produkt, Warenkorb, Checkout. Echte Browser f\u00fchren JavaScript aus und erkennen Client-Seite Fehler, die ein Curl-artiger Check verpasst.<\/li>\n<li><strong>Achten Sie auf Signale im Antwortk\u00f6rper<\/strong>: Schl\u00fcsselw\u00f6rter, Sichtbarkeit von Elementen, erwartete Antwortstruktur. Vertrauen Sie nicht nur dem Statuscode.<\/li>\n<li><strong>Verkn\u00fcpfen Sie Deployments mit dem Monitoring<\/strong>: Jeder Check, der innerhalb von 15 Minuten nach einem Release von gr\u00fcn auf rot springt, sollte das Deployment automatisch taggen. Die H\u00e4lfte der Post-Mortem-Zeit entf\u00e4llt darauf, herauszufinden, was sich ge\u00e4ndert hat; das Monitoring-System wei\u00df das bereits.<\/li>\n<\/ul>\n<h3 id='was-ist-ein-soft-404'  id=\"boomdevs_33\">Was ist ein Soft 404?<\/h3>\n<p>Eine Variante dieses Problems hat einen Namen: das Soft 404. Eine Soft 404-Seite gibt 200 OK zur\u00fcck, sagt aber dem Nutzer, dass der Inhalt nicht existiert \u2013 eine Seite mit einer \u201eNicht gefunden\u201c-Meldung, die mit einem Erfolgs-Code ausgeliefert wird. Googles Empfehlung ist, stattdessen einen echten 404 oder 410 zur\u00fcckzugeben, da Soft 404s Crawl-Budget verschwenden und den Index verwirren, welche Seiten real sind.<\/p>\n<p>Reines Statuscode-Monitoring erkennt ein Soft 404 nicht, aus dem gleichen Grund, warum es einen kaputten Checkout nicht bemerkt: Der Code ist 200. Echte Browser-Checks mit Assertions im Body \u2013 die nach dem erwarteten Inhalt oder dem Fehlen eines \u201enicht gefunden\u201c-Strings suchen \u2013 schon.<\/p>\n<h2 id='wie-http-statuscodes-seo-beeinflussen'  id=\"boomdevs_34\">Wie HTTP-Statuscodes SEO beeinflussen<\/h2>\n<p>Suchmaschinen nutzen Statuscodes, um zu entscheiden, was gecrawlt, indexiert und wie oft eine Seite besucht wird. Drei Muster sind wichtig:<\/p>\n<ul>\n<li><strong>4xx-Codes reduzieren den Index im Laufe der Zeit.<\/strong> Eine Seite, die bei mehreren Crawl-Versuchen 404 zur\u00fcckgibt, wird entfernt. Wenn Sie eine Seite l\u00f6schen, leiten Sie mit 301 um, statt sie einfach 404 geben zu lassen.<\/li>\n<li><strong>5xx-Codes verlangsamen das Crawling und verschlechtern Rankings.<\/strong> Googlebot interpretiert persistente 5xx als \u201ediese Seite ist ungesund\u201c. Die Crawl-Rate sinkt, das Indexieren verlangsamt sich, Rankings k\u00f6nnen fallen.<\/li>\n<li><strong>301 vs 302 ist wichtig.<\/strong> 301 \u00fcbertr\u00e4gt Linkst\u00e4rke. 302 wird als tempor\u00e4r behandelt und unter Umst\u00e4nden nicht. Wenn die \u00c4nderung dauerhaft ist, w\u00e4hlen Sie 301.<\/li>\n<\/ul>\n<p>Die praktische Erkenntnis: 5xx-Fehler sind nicht nur ein Verf\u00fcgbarkeitsproblem. Sie sind ein SEO-Problem, das sich umso mehr auswirkt, je l\u00e4nger es besteht. <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/website-monitoring-errors-dns-tcp-tls-http\/\">DNS-, TCP-, TLS- und HTTP-Fehler<\/a> haben jeweils unterschiedliche SEO-Kosten \u2013 zu wissen, welche Schicht ausf\u00e4llt, hilft bei der schnelleren Fehlerbehebung.<\/p>\n<figure id=\"attachment_33963\" aria-describedby=\"caption-attachment-33963\" style=\"width: 1536px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-33963\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart.webp\" alt=\"Entscheidungs-Flussdiagramm f\u00fcr die Erstbeurteilung von HTTP-Statuscode-Alerts \u2013 welche Schicht zuerst \u00fcberpr\u00fcfen, wann der Bereitschaftsdienst gerufen wird, wann ein Rollback erfolgt\" width=\"1536\" height=\"1024\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart.webp 1536w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2024\/12\/triage-flowchart-768x512.webp 768w\" sizes=\"(max-width: 1536px) 100vw, 1536px\" \/><figcaption id=\"caption-attachment-33963\" class=\"wp-caption-text\">Ein einfacher Triage-Pfad vom Statuscode zum ersten Untersuchungsschritt.<\/figcaption><\/figure>\n<h2 id='http-statuscodes-\u00fcberwachen-ohne-in-alarmen-unterzugehen'  id=\"boomdevs_35\">HTTP-Statuscodes \u00fcberwachen, ohne in Alarmen unterzugehen<\/h2>\n<p>Jedes Team, das HTTP-Traffic \u00fcberwacht, trifft irgendwann auf dasselbe Problem: zu viele Alarme, zu wenig Signal. Einige Praktiken halten Statuscode-Monitoring n\u00fctzlich statt st\u00f6rend.<\/p>\n<p><strong>Alarmieren Sie bei Raten, nicht bei einzelnen Anfragen.<\/strong> Ein einzelner 500er ist Rauschen. F\u00fcnfzig 500er in f\u00fcnf Minuten sind ein Vorfall. Konfigurieren Sie Schwellenwerte anhand Ihres Basisverkehrs.<\/p>\n<p><strong>Trennen Sie nutzerseitige Endpunkte von internen.<\/strong> Ein 500 am Checkout-API sollte page. Ein 500 an einem Admin-Endpunkt, den niemand nutzt, kann bis zu den Gesch\u00e4ftszeiten warten.<\/p>\n<p><strong>Testen Sie von dort, wo Ihre Nutzer sind.<\/strong> Ein Check von einem Rechenzentrum f\u00e4ngt keinen regionalen CDN-Ausfall. Nutzen Sie ein Monitoring-Netzwerk mit mehreren Standorten, um standortbezogene Probleme vor Kunden zu erkennen.<\/p>\n<p><strong>Kombinieren Sie Status-Checks mit Inhaltspr\u00fcfungen.<\/strong> 200 OK ist ein Startpunkt, kein Endpunkt. Pr\u00fcfen Sie, ob die Antwort das enth\u00e4lt, was sie enthalten soll.<\/p>\n<p>Das <a href=\"https:\/\/www.dotcom-monitor.com\/de\/produkte-zur-ueberwachung\/ueberwachung-von-webanwendungen\/\">Web Application Monitoring<\/a> von Dotcom-Monitor deckt alle vier ab: alarm gest\u00fctzte \u00dcberwachung, Endpunkt-Segmentierung, globale Teststandorte und echte Browser-Inhaltspr\u00fcfungen. F\u00fcr API-lastige Stacks erweitert der <a href=\"https:\/\/www.dotcom-monitor.com\/de\/produkte-zur-ueberwachung\/web-api-monitoring\/\">API-Monitoring<\/a>-Weg Schemavalidierung und Antwortzeit-SLOs zus\u00e4tzlich zu Statuscode-Checks. Beides speist dieselbe <a href=\"https:\/\/www.dotcom-monitor.com\/de\/funktionen\/merkmale-warnungen\/\">Alerting<\/a>-Pipeline, sodass Sie nicht Signale von drei Anbietern zusammenf\u00fchren m\u00fcssen.<\/p>\n<h2 id='abschlie\u00dfende-gedanken'  id=\"boomdevs_36\">Abschlie\u00dfende Gedanken<\/h2>\n<p>Die h\u00e4ufigsten HTTP-Statuscodes haben sich seit Jahren nicht ge\u00e4ndert. 200, 301, 404, 500, 502, 503 \u2013 diese werden Sie diese Woche alle sehen. Was sich \u00e4ndert, ist, wie schnell Ihr Team vom \u201eCode sehen\u201c zum \u201eUrsache beheben\u201c kommt.<\/p>\n<p>Diese L\u00fccke ist es, in der gutes Monitoring sich auszahlt. Statuscodes allein sagen: Etwas ist passiert. Mehrschichtige Checks \u2013 Status, Inhalt, echter Browser, Multi-Region \u2013 sagen: Was, wo und was als n\u00e4chstes zu tun ist.<\/p>\n<p>Wenn Sie sehen m\u00f6chten, wie das aussieht, hat <a href=\"https:\/\/www.dotcom-monitor.com\/\">Dotcom-Monitor<\/a> eine kostenlose Testversion. Richten Sie sie auf einen Ihrer Endpunkte aus und sehen Sie, was sie anzeigt.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Eine praktische Referenz f\u00fcr Ingenieure, die gerufen werden, wenn diese Codes erscheinen.<\/p>\n","protected":false},"author":21,"featured_media":33973,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[883],"tags":[],"class_list":["post-12262","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/12262","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=12262"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/12262\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media\/33973"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=12262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=12262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=12262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}