Ein 503 Service Unavailable bedeutet, dass der Webserver die Anfrage erhalten hat, sie aber gerade nicht verarbeiten kann. Der Server ist erreichbar, DNS und Netzwerk funktionieren also, aber die Anwendung dahinter ist überlastet, in Wartung oder erreicht einen Dienst nicht, von dem sie abhängt. Ein 503 ist als vorübergehend gedacht. Dauert er länger als ein paar Minuten, muss etwas behoben werden: meist zu viel Traffic, zu wenige Worker, ein gestoppter Anwendungsprozess oder ein ausgefallenes Backend.
Dieser Leitfaden erklärt, was einen 503 auslöst, wie Sie die Ursache auf Ihrem eigenen Server finden, wie Sie jede beheben und wie Sie sicherstellen, dass Sie vom nächsten erfahren, bevor Ihre Kunden es tun.
Was ein 503 Ihnen tatsächlich sagt
HTTP-Statuscodes im 5xx-Bereich bedeuten, dass der Server gescheitert ist, nicht der Besucher. Innerhalb dieser Familie hat 503 eine bestimmte Bedeutung: Der Dienst ist im Moment nicht verfügbar, und der Client kann es später erneut versuchen. Zum Vergleich die Nachbarn:
500 Internal Server Error: Die Anwendung ist bei der Verarbeitung der Anfrage abgestürzt.
502 Bad Gateway: Ein Proxy oder Load Balancer hat vom Server dahinter eine ungültige Antwort erhalten.
503 Service Unavailable: Der Server oder etwas davor weigert sich, die Anfrage zu verarbeiten, weil er überlastet oder in Wartung ist oder nichts Funktionsfähiges hat, an das er sie schicken kann.
504 Gateway Timeout: Ein Proxy hat auf den Server dahinter gewartet und aufgegeben.
Die Unterscheidung ist wichtig, weil sie zeigt, wo Sie suchen müssen. Ein 503 ist selten ein Bug auf einer einzelnen Seite. Fast immer geht es um Kapazität oder Verfügbarkeit eines ganzen Dienstes. Einen vollständigen Überblick über die Codes und darüber, welche ein Monitoring als Ausfall werten sollte, gibt unser Spickzettel zu HTTP-Statuscodes fürs Monitoring.
Häufige Ursachen für einen 503
Traffic-Spitzen und Überlast
Jeder Server kann nur eine begrenzte Zahl von Anfragen gleichzeitig verarbeiten. Ein Newsletter, eine Erwähnung in sozialen Medien oder ein Bot, der Tausende Seiten crawlt, können ihn über diese Grenze treiben. Ist die Warteschlange voll, beginnt der Webserver oder die Anwendung, neue Anfragen mit 503 abzulehnen. Oft funktioniert die Website ein paar Minuten später wieder und fällt bei der nächsten Spitze erneut aus.
Geplante Wartung
Viele Systeme geben während einer Wartung absichtlich 503 zurück. WordPress macht das, während es Updates installiert: Es schreibt eine .maintenance-Datei und liefert eine kurze Seite „Briefly unavailable for scheduled maintenance“ mit Status 503. Wird ein Update unterbrochen, kann diese Datei liegen bleiben, und die Website liefert weiter 503, bis jemand sie löscht.
Gestoppter Anwendungsprozess oder App-Pool
Auf Windows-Servern mit IIS erzeugt ein gestoppter oder abgestürzter Anwendungspool den klassischen Fehler „HTTP Error 503. The service is unavailable.“ Der Pool kann wegen wiederholter Abstürze, eines falschen Identitätspassworts oder einer Konfigurationsänderung stoppen. Unter Linux entspricht dem ein beendeter Node-, Python- oder Java-Prozess, sodass der Reverse Proxy nichts mehr hat, wohin er weiterleiten kann.
PHP-FPM ohne freie Worker
PHP-Websites hinter nginx oder Apache laufen meist mit PHP-FPM und einer festen Zahl von Worker-Prozessen, festgelegt durch pm.max_children. Sind alle Worker beschäftigt, etwa weil jede Anfrage auf eine langsame Datenbankabfrage oder eine externe API wartet, stauen sich neue Anfragen. Je nach Setup bekommt der Besucher einen 503, 502 oder 504. Das PHP-FPM-Log zeigt Ihnen, ob das passiert:
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Rate Limiting
Rate Limits schützen einen Server vor Missbrauch, liefern aber auch echten Nutzern Fehler, wenn sie zu eng eingestellt sind. nginx gibt standardmäßig 503 zurück, wenn eine Anfrage eine limit_req-Zone überschreitet. Web Application Firewalls und manche Hosting-Plattformen machen es genauso. Teilen sich ein Büro, ein API-Client oder ein Monitoring-Dienst eine IP-Adresse mit vielen Nutzern, können sie das Limit gemeinsam erreichen.
Upstream oder Backend ausgefallen
Load Balancer und Reverse Proxys geben 503 zurück, wenn sie keinen funktionsfähigen Server haben, an den sie Traffic schicken können. Markieren die Health Checks jedes Backend als nicht funktionsfähig, nach einem fehlerhaften Deploy oder weil die Datenbank ausgefallen ist und der Health-Endpunkt das meldet, antwortet der Proxy auf jede Anfrage mit 503.
Probleme mit CDN und Origin
Liegt Ihre Website hinter einem CDN, kann der 503 vom CDN statt von Ihrem Server kommen. Das CDN kann ihn zurückgeben, wenn Ihr Origin überlastet oder nicht erreichbar ist oder wenn das CDN selbst in einer Region Probleme hat. Die Response-Header verraten meist, wer geantwortet hat: Achten Sie auf den eigenen Server-Header oder die Request-ID des CDN und vergleichen Sie mit einer Anfrage direkt an den Origin.
So finden Sie die Ursache
Beginnen Sie mit der Antwort selbst. Rufen Sie die fehlerhafte URL auf und sehen Sie sich die Header an:
curl -sS -o /dev/null -D – https://northwind.shop/checkout
Der Server-Header und eventuelle CDN-spezifische Header zeigen, welche Schicht geantwortet hat. Ein Retry-After-Header deutet auf eine absichtliche Wartung hin. Arbeiten Sie sich dann nach innen vor:
Prüfen Sie, ob es überall auftritt. Scheitert auch die Startseite oder nur ein Pfad? Ein einzelner Pfad deutet auf eine bestimmte Route oder einen Worker-Pool; scheitert alles, liegt es am Server oder Proxy.
Lesen Sie das Error-Log des Webservers. nginx und Apache protokollieren Upstream-Fehler, abgelehnte Anfragen durch Rate Limits und Verbindungsfehler mit Zeitstempel.
Lesen Sie das Log der Anwendung oder von PHP-FPM. Achten Sie auf max_children-Warnungen, Abstürze, Out-of-Memory-Kills und Traces langsamer Anfragen.
Prüfen Sie die Serverressourcen. CPU, Last, Arbeitsspeicher und Swap zum Zeitpunkt des Fehlers. Ein Server, der swappt, antwortet langsam, und langsame Antworten füllen Worker-Pools.
Prüfen Sie die Abhängigkeiten. Antwortet die Datenbank? Läuft der Cache? Antwortet eine externe API, die Sie synchron aufrufen, langsam?
Prüfen Sie kürzliche Änderungen. Ein Deploy, ein Plugin-Update, eine Konfigurationsänderung oder ein neues Rate Limit rund um den Beginn der Fehler ist die wahrscheinlichste Ursache.
So beheben Sie einen 503
Die Lösung richtet sich nach der Ursache. Hier die häufigsten in der Reihenfolge, in der die meisten Teams ihnen begegnen.
Hängengebliebener Wartungsmodus: Entfernen Sie die .maintenance-Datei im WordPress-Stammverzeichnis oder schalten Sie das Wartungs-Flag Ihres Frameworks ab, und schließen Sie das Update dann ab oder wiederholen Sie es.
Überlast durch echten Traffic: Cachen Sie, was möglich ist, am Edge und in der Anwendung, damit die meisten Anfragen PHP oder die Datenbank nie erreichen. Erhöhen Sie dann die Kapazität: mehr Worker, wenn der Speicher reicht, ein größerer Server oder mehr Server hinter dem Load Balancer.
Überlast durch Bots: Ermitteln Sie die User Agents und IP-Bereiche in Ihrem Access-Log und begrenzen oder blockieren Sie sie am CDN oder an der Firewall, bevor sie die Anwendung erreichen.
PHP-FPM-Worker: Erhöhen Sie pm.max_children nur so weit, wie der Speicher es erlaubt. Ermitteln Sie den durchschnittlichen Speicherbedarf eines Workers und teilen Sie den verfügbaren Speicher dadurch. Sind die Worker wegen langsamer Abfragen beschäftigt, beheben Sie zuerst die Abfragen, sonst verschieben Sie nur den Engpass.
Gestoppter App-Pool oder Prozess: Starten Sie ihn neu und finden Sie dann heraus, warum er gestoppt hat. Suchen Sie im Ereignisprotokoll oder System-Journal nach Abstürzen und richten Sie einen Prozessmanager ein, der den Dienst automatisch neu startet.
Zu strenge Rate Limits: Erhöhen Sie das Limit oder die Burst-Größe, nehmen Sie bekannte IP-Adressen wie Ihr Büro oder Ihren Monitoring-Dienst aus und geben Sie für begrenzte Clients 429 statt 503 zurück, damit die Ursache in den Logs offensichtlich ist.
Nicht funktionsfähige Backends: Prüfen Sie, was der Health Check des Load Balancers abfragt und warum er scheitert. Rollen Sie einen fehlerhaften Deploy zuerst zurück und untersuchen Sie danach.
Hier eine typische Änderung am PHP-FPM-Pool für einen Server mit Platz für mehr Worker. Die Zahlen sind ein Beispiel, keine Empfehlung für Ihren Server:
; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 24
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
Der nützliche Teil ist das Slow-Log: Es zeigt, welche Skripte Worker am längsten belegen, und damit, wo Sie als Nächstes suchen sollten.
Retry-After bei geplanter Wartung verwenden
Wenn Sie eine Website absichtlich vom Netz nehmen, geben Sie 503 mit einem Retry-After-Header zurück. Er sagt Browsern, API-Clients und Suchmaschinen-Crawlern, dass der Ausfall vorübergehend ist und wann sie wiederkommen sollen. Der Wert ist entweder eine Anzahl Sekunden oder ein HTTP-Datum:
HTTP/1.1 503 Service Unavailable
Retry-After: 1800
Content-Type: text/html; charset=utf-8
In nginx kann ein einfacher Wartungsschalter so aussehen:
if (-f /var/www/maintenance.flag) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
add_header Retry-After 1800 always;
root /var/www/maintenance;
rewrite ^ /index.html break;
}
Zwei Regeln machen geplante Wartung schmerzlos. Geben Sie 503 zurück, nie 200 mit einer „Gleich wieder da“-Seite, denn ein 200 sagt Crawlern und Monitoren, dass die Wartungsseite Ihr echter Inhalt ist. Und halten Sie die Wartung kurz: Ein 503 für eine Stunde ist in Ordnung, ein 503 über Tage riskiert, dass Seiten aus den Suchergebnissen fallen.
Informieren Sie Ihre Kunden auch vorab. Ein Hinweis auf Ihrer Statusseite beantwortet „Liegt es nur an mir?“, bevor jemand fragt.
Wie Monitoring 503er erkennt
Ein 503 kommt und geht oft. Die Website fällt auf dem Höhepunkt einer Kampagne für zwei Minuten aus, erholt sich und fällt eine Stunde später erneut aus. Niemand im Team sieht es, denn wenn jemand die Website öffnet, funktioniert sie. Die Kunden haben es aber gesehen.
Ein HTTP-Monitor ruft Ihre Seiten nach Zeitplan auf und speichert Statuscode und Antwortzeit jedes Checks. Ein 503 ist ein fehlgeschlagener Check. Gutes Monitoring tut dann drei Dinge:
Es bestätigt den Fehler. Ein zweiter Check schließt einen einmaligen Ausreißer aus, und ein Check von einem anderen Standort schließt zusätzlich ein Problem auf einem einzelnen Netzwerkpfad aus. Uptimecheck prüft aus Stockholm, London und New York und bestätigt jeden Fehler von einem zweiten Standort aus, bevor ein Vorfall eröffnet wird.
Es alarmiert die richtigen Leute. Der Alarm enthält Statuscode, URL und Beginn, sodass jeder, der ihn übernimmt, weiß, dass es ein 503 ist und kein DNS-Fehler. In Uptimecheck enthält der Vorfall außerdem die fehlerhafte Antwort und einen Screenshot, Sie sehen also die Fehlerseite, die Ihre Besucher gesehen haben, oder einen Traceroute, wenn der Server gar nicht geantwortet hat. Die Kanäle finden Sie unter Alarme und Benachrichtigungen.
Es zeichnet das Muster auf. Die Vorfallshistorie zeigt, ob sich 503er um Traffic-Spitzen, Deploys oder nächtliche Jobs häufen, und damit, welche Lösung Sie zuerst versuchen sollten.
Überwachen Sie mehr als die Startseite. Die Startseite ist oft gecacht und funktioniert weiter, während Checkout, Login oder API ausfallen. Richten Sie Uptime-Monitore für die Seiten ein, die Geld verdienen, und behalten Sie den Trend der Antwortzeit im Blick: Eine Seite, die jeden Tag zur selben Stunde langsamer wird, ist oft ein 503, der nur darauf wartet, einzutreten. Unser Leitfaden dazu, was eine gute Antwortzeit für Websites ist, erklärt, worauf Sie achten sollten.
Servermetriken schließen den Kreis. Kommt ein 503-Alarm, lautet die erste Frage, ob dem Server CPU, Arbeitsspeicher oder Festplattenplatz ausgegangen ist. Mit Server-Monitoring neben Ihren Uptime-Checks sehen Sie Ursache und Symptom nebeneinander.
Checkliste für 503-Fehler
Sehen Sie sich die Response-Header an, um zu erkennen, welche Schicht den 503 zurückgegeben hat.
Prüfen Sie die Logs von Webserver, Anwendung und PHP-FPM zum selben Zeitstempel.
Prüfen Sie CPU, Arbeitsspeicher, Swap und Festplatte auf dem Server.
Suchen Sie nach Deploys, Updates und Konfigurationsänderungen kurz vor Beginn der Fehler.
Beheben Sie die Ursache: Caching, mehr Worker, ein neu gestarteter Prozess, ein lockereres Rate Limit oder ein funktionsfähiges Backend.
Verwenden Sie bei geplanter Wartung 503 mit Retry-After, nie 200.
Überwachen Sie wichtige Seiten jede Minute und bestätigen Sie jeden Fehler mit einem zweiten Check, bevor alarmiert wird.
Zusammenfassung
Ein 503 bedeutet, dass der Server da ist, Sie aber gerade nicht bedienen kann. Es ist ein Kapazitäts- oder Verfügbarkeitsproblem, keine kaputte Seite, und die Logs zum selben Zeitstempel führen meist direkt zur Ursache. Beheben Sie die Ursache statt des Symptoms, verwenden Sie Retry-After, wenn die Ausfallzeit geplant ist, und lassen Sie sich vom Monitoring über kurze 503er informieren, die Sie sonst nie sehen würden.
Uptimecheck überwacht Websites, APIs und Server in einem Konto und alarmiert Sie, sobald eine Seite 503 zurückgibt. Starten Sie Ihre 14-tägige kostenlose Testphase, keine Kreditkarte erforderlich.