Wartungsfenster planen: 503 und Retry-After richtig setzen

Der Zeitpunkt steht im eigenen Stundenprofil

Die erste Frage eines Wartungsfensters ist nicht, wie die Wartungsseite aussieht, sondern wann sie ausgeliefert wird. Die übliche Antwort lautet "nachts" und ist damit eine Vermutung. Wer die Reichweitenmessung ohne Cookies im eigenen Bestand hat, kann sie durch eine Messung ersetzen: Aufrufe je Stunde, über vier bis sechs vergleichbare Wochen gemittelt, getrennt nach Werktag und Wochenende. Aus dieser Kurve fällt die Stunde von selbst heraus, und sie liegt oft nicht dort, wo das Bauchgefühl sie vermutet.

Zwei Verzerrungen sind einzurechnen. Erstens die Zeitzone: eine Kurve, die im Bericht in UTC geführt wird, verschiebt sich gegenüber der Ortszeit der Besucher, und bei der Zeitumstellung im Monitoring verschiebt sie sich noch einmal. Zweitens die Zusammensetzung: ein Fachhandel mit Geschäftskunden hat einen scharfen Werktagsgipfel am Vormittag, ein Endkundenshop zwei flache Gipfel mittags und abends. Dieselbe Stunde kann für den einen Betrieb die billigste und für den anderen die teuerste sein.

• Aufrufe je Stunde über mindestens vier Wochen, Werktag und Wochenende getrennt ausgewertet
• Bestellungen, Anfragen und Zahlungsabbrüche je Stunde daneben legen, nicht nur Seitenaufrufe
• Ortszeit der Besucher prüfen, nicht die Zeitzone des Auswertungswerkzeugs
• Wiederkehrende Aufträge berücksichtigen: Importe, Kassenabschlüsse, Schnittstellenabgleiche
• Feiertage und Aktionszeiträume aus dem Mittelwert nehmen, sonst verschiebt ein Ausreißer die Kurve

Ein Punkt wird regelmäßig übersehen: die Stunde mit den wenigsten Besuchern ist nicht zwangsläufig die Stunde mit dem geringsten Schaden. Läuft nachts um drei der nächtliche Bestandsabgleich mit der Warenwirtschaft, ist ein Wartungsfenster genau dort teurer als eines um vier, obwohl die Besucherkurve identisch aussieht. Für Suchmaschinen kommt hinzu, dass die Abrufe nicht aus der Nachbarschaft kommen müssen: Google hält in der eigenen Dokumentation fest, dass der Abruf in der Regel aus den USA erfolgt. Eine deutsche Nachtstunde ist für den Crawler damit keine Randzeit.

Was der Statuscode 503 zusagt

RFC 9110 beschreibt 503 in Abschnitt 15.6.4 als Zustand, in dem der Server die Anfrage vorübergehend nicht bearbeiten kann, wegen einer zeitweiligen Überlast oder wegen geplanter Wartung, und der nach einiger Zeit voraussichtlich behoben ist. Das ist die ganze Zusage: nicht "kaputt", nicht "weg", sondern "gerade nicht, später wieder". Genau diese Bedeutung fehlt jeder Wartungsseite, die mit 200 ausgeliefert wird.

The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.

— RFC 9110, Abschnitt 15.6.4

Die Gegenprobe steht im Blog von Google Search Central vom 25. Januar 2011 und ist seither nicht widerrufen worden: statt einen Code 404 zurückzugeben oder eine Fehlerseite mit Status 200 zu zeigen, sei es besser, einen 503 zu senden, der Crawlern sagt, dass die Unterbrechung nur vorübergehend ist. Dasselbe Dokument nennt den Retry-After-Kopf als optionale Angabe der Dauer in Sekunden oder des voraussichtlichen Endzeitpunkts, die Googlebot für den nächsten Abruf auswerten kann. Und es warnt davor, 503 als Dauerlösung zu behandeln: anhaltende 503-Antworten können irgendwann als Zeichen gewertet werden, dass der Server dauerhaft nicht mehr verfügbar ist, und zur Entfernung von Adressen aus dem Index führen.

Wie kurz "vorübergehend" gemeint ist, sagt Google Search Central in der Anleitung zum vorübergehenden Pausieren eines Online-Geschäfts. Dort steht, dass eine dringende Abschaltung von ein bis zwei Tagen über eine informative Fehlerseite mit Statuscode 503 statt über den gesamten Inhalt gefahren wird, und im selben Abschnitt, dass dies eine extreme Maßnahme ist, die nur für einen sehr kurzen Zeitraum ergriffen werden sollte, höchstens einige Tage. Ein einstündiges Wartungsfenster liegt weit darunter und ist damit unkritisch, ein Umzug über ein ganzes Wochenende schon weniger.

Retry-After: zwei Formate, eine Entscheidung

RFC 9110 legt in Abschnitt 10.2.3 fest, dass der Wert von Retry-After entweder ein HTTP-Datum oder eine Anzahl Sekunden ist, um die der Abruf nach Empfang der Antwort verzögert werden soll. Für die Sekundenform gilt dabei, dass es sich um eine nicht negative ganze Dezimalzahl handelt, die eine Zeit in Sekunden darstellt. Zusammen mit einer 503-Antwort gibt Retry-After nach derselben Stelle an, wie lange der Dienst dem Aufrufer voraussichtlich nicht zur Verfügung steht. In Abschnitt 15.6.4 steht dazu, dass der Server einen solchen Kopf senden darf, um eine angemessene Wartezeit vorzuschlagen - eine Erlaubnis, keine Pflicht.

In der Praxis ist die Sekundenform der ruhigere Weg. Sie rechnet ab dem Empfang der Antwort und bleibt damit richtig, auch wenn eine Antwort kurz in einem Zwischenspeicher hängt. Das Datum ist dort im Vorteil, wo das Ende des Fensters vertraglich feststeht und die Angabe auch für Menschen lesbar sein soll. Google Search Central empfiehlt in der Anleitung zum Pausieren schlicht, den Retry-After-Kopf mit einem nach bestem Wissen gesetzten Datum oder einer Dauer zu verwenden - welche der beiden Formen es sein soll, bleibt offen.

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Cache-Control: no-store
Content-Type: text/html; charset=utf-8
Content-Length: 1184

<!doctype html>
<html lang="de"><head><meta charset="utf-8">
<title>Wartung bis 04:00 Uhr</title>
<style>body{font:16px/1.5 system-ui,sans-serif;margin:3rem auto;max-width:36rem}</style>
</head><body>...</body></html>

Ob der Kopf tatsächlich so ausgeliefert wird, sieht man nicht im Quelltext der Seite, sondern nur in der Antwort. Ein Blick auf die HTTP-Kopfzeilen vor dem Termin kostet eine Minute und klärt zugleich, ob ein vorgelagerter Zwischenspeicher oder ein Lastverteiler den Kopf unterwegs entfernt - ein Fall, der öfter vorkommt, als die Serverkonfiguration vermuten lässt.

Drei Auslieferungsfehler, die vor dem Termin messbar sind

Die Wartung selbst ist geplant, ihre Auslieferung meistens nicht. Drei Fehler tauchen dabei immer wieder auf, und alle drei lassen sich am Tag davor an einer Testinstallation nachstellen und messen.

Der zweite Punkt verdient eine eigene Betrachtung, weil seine Folgen am längsten nachwirken. Die robots.txt-Spezifikation von Google beschreibt den Umgang mit 5xx-Antworten auf diese Datei in Stufen: in den ersten zwölf Stunden stellt Google das Crawling der Website ein und versucht weiter, die Datei zu holen. Gelingt das nicht, wird für die nächsten dreißig Tage die letzte brauchbare Fassung verwendet, während der Abruf einer neuen weiterläuft. Liegt gar keine zwischengespeicherte Fassung vor, geht Google davon aus, dass keine Crawl-Einschränkungen bestehen. Für den Inhalt der Datei nennt dieselbe Quelle eine übliche Zwischenspeicherung von bis zu vierundzwanzig Stunden, die bei Zeitüberschreitungen oder 5xx-Fehlern länger ausfallen kann.

• Die robots.txt wird von der Wartungsregel ausgenommen und antwortet weiter mit 200
• Die Sperrregel greift auf Seiten und Ressourcen, nicht auf Steuerdateien
• Wer die Datei während der Wartung ohnehin nicht ausliefern kann, hält das Fenster kurz
• Nach dem Fenster wird der Abruf der Datei einmal nachgemessen, nicht angenommen

Was bei 5xx mit Crawl-Rate und Index passiert

Google beschreibt das Verhalten der eigenen Crawler bei Serverfehlern in einem eigenen Dokument. Der Kern: Serverfehler aus der 5xx-Familie und der Code 429 veranlassen die Crawler, das Crawling vorübergehend zu verlangsamen. Die Absenkung erfolgt dabei nicht pauschal, sondern im Verhältnis zur Zahl der einzelnen Adressen, die einen Serverfehler liefern. Ein einstündiges Fenster mit wenigen betroffenen Adressen ist damit etwas anderes als ein Wochenende, in dem jede Adresse der Domain mit 503 antwortet.

1. Während des Fensters: die Crawl-Rate sinkt, bereits indexierte Adressen bleiben zunächst im Index
2. Bei anhaltenden Serverfehlern: die Indexierungsstrecke entfernt Adressen, die dauerhaft einen Serverfehler liefern
3. Nach der Rückkehr auf 2xx: Google erhöht die Crawl-Rate nach eigener Angabe schrittweise wieder

Eine Nebenwirkung wird selten bedacht: solange eine Seite mit 503 antwortet, können Titel, Beschreibungen, Metadaten und strukturierte Daten dieser Seite nach Angabe von Google nicht aufgefrischt werden. Wer im selben Zeitraum eine Preisänderung oder einen neuen Seitentitel ausrollt, wartet danach länger auf deren Sichtbarkeit. Wo das eine Rolle spielt, gehört das Fenster nicht in dieselbe Woche wie die Änderung, und das SEO-Monitoring läuft danach einmal bewusst gegen die betroffenen Adressen.

Der Unterschied zwischen einem geplanten 503 und einer stillen Fehlkonfiguration ist für die Auswertung wichtig. Wer falsche Statuscodes auf Fehlerseiten schon einmal gesucht hat, kennt das Muster: die Seite sieht richtig aus, der Kopf sagt etwas anderes. Beim Wartungsfenster ist es dieselbe Prüfung, nur mit umgekehrtem Vorzeichen.

Die Wartungsseite: statisch, leicht, ohne fremde Ressourcen

Die Wartungsseite ist die einzige Seite, die während des Fensters funktionieren muss - und ausgerechnet sie hängt häufig an genau der Infrastruktur, die gerade abgeschaltet ist. Google Search Central empfiehlt für diesen Fall, externe Ressourcen zu minimieren und stattdessen eingebettete Stilvorlagen und base64-kodierte Bilder zu verwenden. Übersetzt heißt das: eine Datei, kein Schriftartenabruf, keine Anbindung an das Inhaltsverwaltungssystem, keine Datenbank. Der Blogbeitrag von 2011 geht noch einen Schritt weiter und nennt es eine gute Idee, für geplante Wartungsarbeiten wie Hardwarewartung einen separaten Server bereitzuhalten, der den 503 tatsächlich ausliefert.

• Statuscode 503 und Retry-After im Antwortkopf, nicht nur im Text der Seite
• Ein voraussichtliches Rückkehrdatum im Klartext, damit Besucher nicht raten müssen
• Ein Kontaktweg, der außerhalb der gewarteten Anwendung funktioniert
• Eingebettetes CSS statt verlinkter Dateien, Bilder eingebettet oder weggelassen
• Kein noindex-Kopf und kein 403, 404 oder 410 als Ersatz für den 503
• Die Seite liegt dort, wo sie auch bei abgeschalteter Anwendung erreichbar bleibt

Für den Sonderfall der längeren Schließung - Betriebsferien, Umbau, Saisonpause - gilt eine andere Empfehlung. Google schreibt, dass für eine längere Abschaltung eine indexierbare Startseite als Platzhalter mit Statuscode 200 bereitgestellt werden sollte, damit Nutzer den Betrieb in der Suche weiterhin finden. Der 503 ist das Werkzeug für Stunden und Tage, nicht für Wochen.

Caching: ein 503 darf nicht hängenbleiben

Nach RFC 9110 gilt nur ein Teil der Statuscodes als heuristisch zwischenspeicherbar; die Spezifikation zählt in Abschnitt 15.1 zwölf davon auf - 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 und 501 - und stellt fest, dass alle übrigen Codes es nicht sind. Der 503 gehört also nicht dazu, und das ist gut so. Gefährlich wird es erst, wenn ein vorgelagerter Zwischenspeicher eine ausdrückliche Gültigkeitsdauer mitgeliefert bekommt: RFC 9111 hält in Abschnitt 4.2.2 fest, dass ein Zwischenspeicher keine Heuristik zur Bestimmung der Frische verwenden darf, wenn in der gespeicherten Antwort eine ausdrückliche Ablaufzeit steht. Steht dort versehentlich eine lange Gültigkeit, bleibt die Wartungsseite länger stehen als die Wartung dauert.

Alarm unterdrücken, Messung weiterlaufen lassen

Ein geplantes Fenster ohne gesetzte Alarmunterdrückung erzeugt genau die Alarme, die niemand liest - und gewöhnt das Team daran, Meldungen wegzuklicken. Wie aus stillen Fenstern falsche Alarme werden, steht ausführlich unter Wartungsfenster und falsche Alarme. Wichtig ist die Form: das Fenster braucht ein Ende, nicht nur einen Anfang. Eine Unterdrückung, die von Hand wieder eingeschaltet werden muss, ist die häufigste Ursache dafür, dass der nächste echte Ausfall unbemerkt bleibt.

1. Fenster mit Anfang und Ende setzen, mit Puffer vor dem Start und nach dem geplanten Abschluss
2. Alarmierung unterdrücken, Messung weiterlaufen lassen - die Daten der Stunde werden später gebraucht
3. Eine Prüfung behalten, die auf den erwarteten 503 und den Retry-After-Kopf schaut statt auf 200
4. Das Fenster in der Alarmierung dokumentieren, damit Vertretungen es sehen
5. Nach dem Ende einmal bestätigen, dass die Alarmierung wieder scharf ist

Nach außen gehört das Fenster auf die Statusseite, und zwar vorher. Eine Statusseite mit Reporting nimmt die Ankündigung auf und trägt sie während des Fensters weiter; wie eine solche Seite für Kunden aufgesetzt wird, steht unter Statusseite für Kunden einrichten. Der Nebeneffekt ist praktisch: wer die Ankündigung liest, ruft nicht an.

Die Probe vor dem Termin

Alle Aussagen dieses Beitrags lassen sich vor dem Termin prüfen, und zwar an derselben Stelle, an der später die Besucher stehen: in der Antwort des Servers. Die Wartungsregel wird dafür an einer Testinstallation oder für eine einzelne Adresse eingeschaltet und die Antwort gelesen.

Eine Messfalle steckt in der Abkürzung: wer curl mit dem Schalter für Weiterleitungen aufruft, bekommt den Statuscode des Ziels und nicht den der Wartungsseite. Aus einer 302 auf eine Seite mit 200 wird in der Ausgabe eine glatte 200, und die Weiterleitungsfalle bleibt unentdeckt. Deshalb ohne diesen Schalter messen und die Kette Schritt für Schritt ansehen. Für den schnellen Blick genügt ein Statuscode-Test, für die Steuerdateien der Abruf von robots.txt und Sitemap.

• Statuscode der Startseite ist 503, nicht 200 und nicht 404
• Retry-After steht im Antwortkopf und trägt Sekunden oder ein Datum
• robots.txt antwortet weiter mit 200 und enthält keine neue Sperrregel
• sitemap.xml und die Statusseite sind von der Wartungsregel ausgenommen
• Kein noindex im Antwortkopf und kein noindex im Kopf der Wartungsseite
• Die Wartungsseite lädt keine Datei nach, die auf der gewarteten Anwendung liegt

Nach dem Fenster wird die Rückkehr gemessen

Das Fenster endet nicht, wenn die Anwendung wieder läuft, sondern wenn die Rückkehr belegt ist. Google erhöht die Crawl-Rate nach eigener Angabe schrittweise wieder, sobald der Server mit einem 2xx-Code antwortet - das geschieht von selbst, ist aber kein Ersatz für die eigene Kontrolle. Die erste Messung nach dem Fenster gilt dem Statuscode, die zweite dem Zwischenspeicher, die dritte der Alarmierung.

• Startseite und zwei Unterseiten antworten wieder mit 200, Retry-After ist verschwunden
• Kein 503 mehr im Auslieferungsnetz, stichprobenartig gegen mehrere Orte gemessen
• robots.txt und sitemap.xml unverändert und erreichbar
• Alarmierung wieder scharf, Wartungsfenster geschlossen statt offen stehengelassen
• Antwortzeiten der ersten Stunde angesehen: ein kalter Zwischenspeicher sieht aus wie eine Störung

Wenn nach dem Fenster etwas nicht stimmt, ist die Ursache häufig nicht die Wartung selbst, sondern die Änderung, die dabei eingespielt wurde. Das Vorgehen dafür steht unter Deploy-Fehler als Ausfallursache; der Unterschied zur Wartung ist, dass ein Rückfall auf den vorherigen Stand hier eine Option bleibt, solange dieser Stand vorgehalten wird.

Wartungsfenster im Vertrag und vor dem Jahresendgeschäft

Ein angekündigtes Wartungsfenster ist in den meisten Vereinbarungen von der Verfügbarkeitsrechnung ausgenommen - aber nur, wenn es angekündigt war, im vereinbarten Rahmen lag und dokumentiert ist. Wie sich Messpunkt, Ausnahmen und Service-Gutschriften sauber fassen lassen, steht unter SLA-Streit mit dem Kunden. Für Agenturen ist die praktische Folge einfach: das Fenster wird schriftlich angekündigt, die Messung läuft weiter, und beides liegt später als Beleg vor.

Vor dem Jahresendgeschäft verschiebt sich die Rechnung zusätzlich. Was im März eine ruhige Nachtstunde ist, kann im November eine Aktionsnacht sein. Wer die Lastspitzen des Jahresendgeschäfts vorbereitet, legt Wartungsfenster deshalb vor die heiße Phase und friert sie währenddessen ein. Das Stundenprofil aus dem Vorjahr ist dafür die bessere Grundlage als das des laufenden Monats.