Lastspitzen im Q4: Website vor dem Weihnachtsgeschäft härten

Warum das vierte Quartal ein eigenes Betriebsfenster ist

Ein Ausfall kostet nicht überall gleich viel. Er kostet, was in derselben Zeitspanne sonst geschehen wäre, und genau diese Bezugsgröße verschiebt sich zum Jahresende. Das Statistische Bundesamt weist für den Dezember 2025 einen realen Umsatzzuwachs von 3,2 Prozent gegenüber dem Vorjahresmonat aus, nominal waren es 3,5 Prozent (Destatis). Über das gesamte Jahr 2025 lag der reale Zuwachs bei 2,7 Prozent (Destatis). Der Dezember zieht damit stärker an als das Jahr, in dem er liegt. Dazu kommt die Eigenart dieses Fensters: Wer am 20. Dezember keinen Warenkorb abschließen kann, kauft erfahrungsgemäß nicht am 27. nach, sondern anderswo oder gar nicht. Wie sich ein solcher Verlust überhaupt beziffern lässt, ist im Beitrag Kosten eines Website-Ausfalls berechnen beschrieben.

Die Größenordnung des Fensters lässt sich mit zwei Zahlen fassen. Der Handelsverband Deutschland prognostizierte für November und Dezember 2025 einen Einzelhandelsumsatz von 126,2 Milliarden Euro (HDE), und auf dieselben zwei Monate entfallen 18,5 Prozent des gesamten Jahresumsatzes (HDE). Ein Sechstel des Jahres trägt damit fast ein Fünftel des Ergebnisses. Für die Technik hinter einem Shop heißt das: Dieselbe Verfügbarkeitszahl bedeutet im Dezember etwas anderes als im Juli. Ein Monat mit 99,5 Prozent Verfügbarkeit lässt rechnerisch rund 3,7 Stunden Ausfall zu, also ein halbes Prozent von 744 Stunden. Im Juli ist das ein Ärgernis. In der Woche vor Weihnachten ist es eine Zahl, die in der Jahresauswertung sichtbar wird.

• 126,2 Milliarden Euro Umsatz im Einzelhandel prognostizierte der HDE für November und Dezember 2025, nominal 1,5 Prozent mehr als im Vorjahr und preisbereinigt ein Nullwachstum (HDE).
• 18,5 Prozent des Jahresumsatzes entfallen nach derselben Rechnung auf diese beiden Monate (HDE).
• 22,2 Milliarden Euro davon entfallen auf den Onlinehandel, nominal 3,3 Prozent mehr als 2024 (HDE).
• 5,8 Milliarden Euro erwartete der HDE allein für Black Friday und Cyber Monday 2025, rund 1,6 Milliarden Euro davon als Weihnachtseinkäufe (HDE).
• 3,2 Prozent real mehr Umsatz als im Vorjahresmonat meldete das Statistische Bundesamt für den Dezember 2025 (Destatis).
• 4,4 Prozent nominales Wachstum erwartet der HDE für den Onlinehandel im Jahr 2026, bei zwei Prozent für den Einzelhandel insgesamt (HDE).

Diese Zahlen sind Prognosen und Umfragewerte, keine Kassenbons. Der HDE stützt seine Weihnachtsprognose auf eine Umfrage unter 300 Handelsunternehmen und eine Verbraucherbefragung des Handelsblatt Research Institute unter mehr als 2.000 Personen (HDE); die Jahresprognose für 2026 beruht auf einer Umfrage unter knapp 600 Handelsunternehmen (HDE). Sie taugen deshalb zur Größenordnung, nicht zur Planung einzelner Stunden. Für die technische Vorbereitung reicht die Größenordnung aus: Sie sagt, dass zwei Monate ein knappes Fünftel tragen, und sie sagt, wann. Alles Weitere kommt aus den eigenen Messwerten der Vorjahre, und genau die sollten jetzt aus der Auswertung geholt werden, solange noch Zeit bleibt, etwas zu ändern.

Die Lastkurve entsteht nicht am Black Friday

Wer den Peak auf einen Tag legt, plant am tatsächlichen Verlauf vorbei. Black Friday fiel 2025 auf den 28. November, Cyber Monday auf den 1. Dezember (HDE). Der HDE erwartete für diese Aktionstage 5,8 Milliarden Euro Umsatz, davon rund 1,6 Milliarden Euro Weihnachtseinkäufe (HDE); 54 Prozent der Befragten gaben an, den Black Friday auch für Weihnachtseinkäufe zu nutzen, für den Cyber Monday sagten das 42 Prozent (HDE, Umfrage des IFH Köln unter über 1.000 Onlineshoppern im Oktober 2025). Das verschiebt Nachfrage nach vorn, ohne den Dezember zu leeren. Die Folge ist keine Spitze, sondern ein Plateau: erhöhte Last ab der zweiten Novemberwoche, ein Maximum um die Black Week, ein zweiter Anstieg um den zweiten und dritten Advent, danach ein Abfall, den der letzte zugesagte Liefertermin bestimmt.

Für den Betrieb hat dieses Plateau eine unangenehme Eigenschaft: Es dauert länger als jedes Wartungsfenster, das man dafür freihalten könnte. Ein Ausfall am Black Friday ist sichtbar und wird sofort bearbeitet. Schwerer wiegen die stillen Verschlechterungen über Wochen: eine Datenbankabfrage, die unter Last von 80 auf 900 Millisekunden wächst, ein Bildverzeichnis, das langsam den Plattenplatz füllt, ein Zahlungsdienst, der bei jedem zwanzigsten Aufruf in einen Zeitüberlauf läuft. Nichts davon erzeugt eine Fehlerseite, und nichts davon zeigt ein Verfügbarkeitswert von 99,9 Prozent an. Solche Verläufe stehen in der Antwortzeitverteilung und in der Fehlerrate, nicht im Ampelzustand.

Change-Freeze: was eingefroren wird und was nicht

Ein Change-Freeze ist eine Verabredung, keine technische Sperre. Er legt fest, ab welchem Datum welche Art von Änderung eine ausdrückliche Freigabe braucht. Der Zweck ist nicht, das Team zu bremsen, sondern die Zahl gleichzeitig veränderlicher Größen zu senken: Wenn während der Hochlastphase drei Dinge zugleich anders sind, dauert die Ursachensuche bei einem Vorfall ein Vielfaches. Sinnvoll ist ein gestufter Freeze. Ab Mitte Oktober gehen nur noch Änderungen mit geprobtem Rückweg live, ab Kalenderwoche 45 nur noch Fehlerbehebungen mit benanntem Risiko, und ab dem Beginn der Black Week gilt der engste Rahmen. Nach dem Peak wird der Freeze in derselben Reihenfolge zurückgenommen.

1. Eingefroren: Layout- und Themeänderungen, neue Zahlungs- oder Versandarten, Umstellungen an Kategoriestruktur und Adressen, Aktualisierungen von Erweiterungen ohne Sicherheitsbezug, Wechsel der PHP- oder Datenbankversion.
2. Mit Freigabe möglich: Preis- und Bestandsänderungen, redaktionelle Inhalte, Aktionsbanner sowie Konfigurationswerte, die sich ohne Neuveröffentlichung zurücksetzen lassen.
3. Vom Freeze ausgenommen: Sicherheitsaktualisierungen zu einer bekannten, ausgenutzten Schwachstelle, Zertifikatserneuerungen, Fristsachen wie eine ablaufende Domain und alles, was einen laufenden Vorfall beendet.
4. Ohne Rückfrage erlaubt: das Zurückrollen auf den letzten bekannten guten Stand.
5. Schriftlich festgehalten: wer freigeben darf, über welchen Weg die Freigabe eingeholt wird und wie lange auf eine Antwort gewartet wird, bevor die Ausweichentscheidung greift.

Der Freeze braucht ein zweites Element, damit er trägt: einen belastbaren Rückweg. Vor dem 1. November sollte einmal geprobt worden sein, wie lange eine Rückkehr auf den vorherigen Stand tatsächlich dauert, einschließlich Datenbankmigrationen, Cachewarmlauf und Neuaufbau der Suchindizes. Gemessen wird dabei die Dauer, die auf der Uhr steht, nicht die, die im Plan steht. Wer die Probe erst im Vorfall fährt, misst sie unter den ungünstigsten Bedingungen. Zum Rückweg gehört auch die Frage, was mit Bestellungen geschieht, die zwischen Veröffentlichung und Rücknahme angelegt wurden. Für die Cacheschichten, die nach einem solchen Wechsel gern alte Seiten weiterreichen, ist der Beitrag veraltete Seiten nach dem Deploy finden einschlägig.

Prüfintervalle für das Hochlastfenster

Das Prüfintervall bestimmt die Erkennungszeit, und die Erkennungszeit bestimmt den Schaden. Bei einem Fünfminutenintervall vergehen im Mittel zweieinhalb Minuten und im ungünstigsten Fall fünf Minuten, bis ein Ausfall überhaupt auffällt; dazu kommen die Bestätigung durch einen zweiten Standort und der Weg der Benachrichtigung. Ein Minutenintervall verkürzt den Mittelwert auf dreißig Sekunden. Was das für die Auswahl bedeutet und wo engere Intervalle in Fehlalarme umschlagen, ist im Beitrag Uptime-Check-Intervall wählen ausgeführt. Für das vierte Quartal lautet die Regel schlicht: Was Umsatz trägt, wird enger geprüft, und die Umstellung geschieht vor dem Freeze, nicht während der Black Week.

Zwei Zeilen dieser Tabelle verdienen eine Begründung. Die stündliche Prüfung von Warenkorb und Kasse ist der zuverlässigste Weg, eine Störung zu bemerken, die nur angemeldete Kunden trifft oder erst im dritten Schritt auftritt: Die Startseite antwortet dabei mit Statuscode 200, und trotzdem kommt keine Bestellung zustande. Das Vorgehen dafür beschreibt der Beitrag Login-Flow überwachen und Checkout prüfen. Die zweite Zeile ist die Zertifikatsschwelle: 45 Tage klingen großzügig, decken aber genau den Fall ab, dass eine Erneuerung in den Freeze fällt und deshalb erst nach der Black Week bearbeitet wird.

Nicht nur erreichbar: was im vierten Quartal gemessen wird

Eine Statusampel beantwortet eine Frage, die im vierten Quartal zu grob ist. Zwischen erreichbar und ausgefallen liegt der Bereich, in dem die meisten Umsatzverluste entstehen: Seiten, die nach elf Sekunden aufbauen, Warenkörbe, die beim Absenden leer zurückkommen, ein Zahlungsdienst, der jede zwanzigste Anfrage abweist. Die Prüfungen setzen deshalb auf mehreren Ebenen an und laufen in derselben Zeitachse zusammen, damit ein Anstieg der Antwortzeit und ein Ausschlag der Fehlerrate als ein Ereignis lesbar werden statt als zwei voneinander unabhängige Meldungen.

Ergänzend gehört in dieses Bild, was die Seite von außen zeigt und was von innen nicht auffällt. Wenn ein vorgelagerter Zwischenspeicher noch ausliefert, während der Ursprungsserver bereits ablehnt, sieht die Messung von außen gesund aus und die Bestellungen brechen trotzdem ab; dieser Fall ist im Beitrag Origin hinter dem CDN überwachen beschrieben. Gleiches gilt für die Herkunft der Zugriffe: Läuft der Shop hinter einem Lastverteiler, entscheidet die richtige Auswertung der weitergereichten Adresse darüber, ob eine Lastspitze aus echten Kunden oder aus einem einzelnen Werkzeug besteht, wie im Beitrag X-Forwarded-For richtig auswerten gezeigt. Welche Prüfungen ein Shop dauerhaft braucht, fasst der Beitrag E-Commerce-Monitoring zusammen.

Antwortzeit unter Last: Perzentile statt Mittelwert

Der Mittelwert der Antwortzeit ist die Kennzahl, die eine Lastspitze am zuverlässigsten verschweigt. Zehn Messungen zwischen 180 und 1.450 Millisekunden ergeben einen Mittelwert von 443,5 Millisekunden. Diese Zahl beschreibt keinen einzigen der zehn Aufrufe: Acht lagen deutlich darunter, zwei deutlich darüber, und genau diese zwei sind die Kunden, die abspringen. Das 95. Perzentil derselben Reihe liegt bei 1.450 Millisekunden und benennt damit den Rand, an dem das Erlebnis kippt. Auch die Schwellenwerte der Core Web Vitals sind aus diesem Grund auf ein Perzentil bezogen: Als Messgröße gilt dort das 75. Perzentil der Seitenaufrufe, getrennt nach mobilen und stationären Geräten (web.dev).

// Perzentil aus einer Messreihe: sortieren, Rang bestimmen, Wert lesen
function perzentil(werte, p) {
  const reihe = [...werte].sort((a, b) => a - b);
  if (reihe.length === 0) return null;   // keine Messung, nicht 0
  const rang = Math.ceil((p / 100) * reihe.length) - 1;
  return reihe[Math.min(Math.max(rang, 0), reihe.length - 1)];
}

// Zehn Antwortzeiten einer Kassenseite in Millisekunden
const antwortzeiten = [180, 190, 205, 210, 230, 260, 310, 420, 980, 1450];

const mittel = antwortzeiten.reduce((a, b) => a + b, 0) / antwortzeiten.length;
console.log(mittel);                       // 443.5
console.log(perzentil(antwortzeiten, 50)); // 230
console.log(perzentil(antwortzeiten, 95)); // 1450

Für das vierte Quartal ist die absolute Zahl weniger wichtig als ihre Bewegung. Eine Kasse, die im Oktober im 95. Perzentil bei 600 Millisekunden liegt und Mitte November bei 1.900, hat ein Problem, auch wenn kein fester Grenzwert überschritten ist. Deshalb gehört die Schwelle im Hochlastfenster an eine Baseline und nicht an eine feste Zahl: gemessen wird gegen die eigene Vorwoche zur gleichen Wochenstunde. Zur Einordnung der Zielmarken bleiben die Core Web Vitals nützlich, die für den größten Inhaltsaufbau 2,5 Sekunden, für die Reaktion auf Eingaben 200 Millisekunden und für die Layoutstabilität einen Wert von 0,1 nennen (web.dev). Wie sich Perzentile sauber bilden und lesen lassen, steht im Beitrag p95 und p99 statt Durchschnitt.

Eine Lastspitze wird selten dadurch überstanden, dass mehr Rechenleistung bereitsteht. Sie wird dadurch überstanden, dass die Verschlechterung zwei Wochen vorher jemandem aufgefallen ist.

— XICTRAQ

Fristen, die mitten in das Hochlastfenster fallen

Zertifikate laufen nicht nach Kalenderjahr ab, sondern nach Ausstellungsdatum, und ihre zulässige Laufzeit ist zuletzt deutlich kürzer geworden. Nach den Baseline Requirements des CA/Browser Forum dürfen Zertifikate, die am oder nach dem 15. März 2026 und vor dem 15. März 2027 ausgestellt werden, eine Gültigkeitsdauer von 200 Tagen nicht überschreiten; empfohlen sind höchstens 199 Tage (CA/Browser Forum). Ein Zertifikat, das im April 2026 ausgestellt wurde, läuft damit im Oktober oder November 2026 ab, also mitten im Hochlastfenster. Ab dem 15. März 2027 sinkt die Obergrenze auf 100 Tage, ab dem 15. März 2029 auf 47 Tage (CA/Browser Forum). Wer die Erneuerung bisher einmal im Jahr von Hand erledigt hat, bekommt im vierten Quartal 2026 zum ersten Mal ein Terminproblem.

• Ablaufdatum aller Zertifikate prüfen, einschließlich Zwischenzertifikaten und Zertifikaten auf Subdomains, und die Warnschwelle auf 45 Tage setzen.
• Automatische Erneuerung testen, indem ein Zertifikat vorzeitig erneuert wird; ein Erneuerungsauftrag, der seit Monaten stumm scheitert, fällt sonst erst am Ablauftag auf.
• Ablaufdaten von Domains und Weiterleitungsdomains prüfen, dazu die hinterlegten Zahlungsdaten beim Registrar.
• Gültigkeit der Zugangsschlüssel für Zahlungs- und Versanddienste notieren; abgelaufene Schlüssel erzeugen Fehler, die wie Lastprobleme aussehen.
• Angekündigte Wartungsfenster der eingebundenen Dienste abfragen und in denselben Kalender eintragen wie die eigenen.
• Empfängerlisten und Rufnummern der Alarmierung prüfen; eine Adresse, die seit dem Sommer nicht mehr besetzt ist, fällt sonst im Vorfall auf.

Alarmierung, Eskalation und der Weg zurück

Ein Ausfall beginnt für den Betrieb nicht, wenn er eintritt, sondern wenn ihn jemand annimmt. Zwischen beiden Zeitpunkten liegen Erkennungszeit, Zustellzeit und Reaktionszeit. Im Hochlastfenster ist die Reaktionszeit der Teil, der am häufigsten unterschätzt wird: Der Alarm geht abends um halb neun an eine Adresse, die zu diesem Zeitpunkt niemand liest. Deshalb gehören zur Vorbereitung eine benannte Bereitschaft mit Vertretung, ein zweiter Kanal neben der E-Mail und eine Eskalationsstufe, die nach zehn Minuten ohne Annahme greift. Der Aufbau einer solchen Kette ist im Beitrag Incident Management und Eskalation beschrieben.

Der erste Aufruf im Beispiel zeigt, worauf es dabei ankommt: Der Statuscode 503 signalisiert nach RFC 9110, dass ein Server eine Anfrage wegen vorübergehender Überlastung oder geplanter Wartung nicht bearbeiten kann, und der Server kann über das Kopffeld Retry-After angeben, wie lange ein Client vor einer Folgeanfrage warten sollte (RFC 9110). Diese Angabe ist im Hochlastfenster mehr als Formsache: Sie unterscheidet für Suchmaschinen und für die eigene Auswertung eine geplante Abweisung von einem Zusammenbruch. Eine Wartungsseite, die mit Statuscode 200 antwortet, wird dagegen als gültiger Inhalt behandelt. Wie Wartungsfenster gesetzt werden, ohne die Alarmkette zu fluten, steht im Beitrag Wartungsfenster im Monitoring.

Statusseite und Wartungsfenster vor dem Peak

Im vierten Quartal steigt mit der Last auch die Zahl der Anfragen, die während einer Störung im Kundenservice auflaufen. Eine öffentliche Statusseite nimmt einen Teil davon vorweg, indem sie den Zustand nennt, bevor jemand fragt. Sie sollte vor dem Freeze eingerichtet, mit einem Testvorfall geprobt und in der Fußzeile verlinkt sein. Wichtig ist dabei die Trennung: Die Statusseite gehört nicht auf dieselbe Infrastruktur wie der Shop, sonst ist sie in genau dem Moment nicht erreichbar, in dem sie gebraucht wird. Wie eine solche Seite aufgebaut und betextet wird, beschreibt der Beitrag Statusseite einrichten.

Geplante Wartungsfenster gehören in dieselbe Ansicht und in dieselbe Kalenderwoche wie der Freeze-Plan. Ein Fenster, das im Monitoring hinterlegt ist, unterdrückt die Alarme für den betroffenen Zeitraum und erscheint zugleich als angekündigter Eintrag auf der Statusseite. Damit entfällt ein häufiger Grund für Alarmmüdigkeit im Dezember: eine Kette von Meldungen, die alle bekannt sind. Für das vierte Quartal empfiehlt es sich, Wartungsfenster in die frühen Morgenstunden zu legen, sie auf 30 Minuten zu begrenzen und für jedes Fenster vorab festzuhalten, wann es als gescheitert gilt und der Rückweg gezogen wird. Die Statusseite und Berichte lassen sich dafür an denselben Datenstand hängen.

Der Ablaufplan von Mitte September bis zur Black Week

Aus den vorangegangenen Abschnitten wird ein Kalender. Die Kalenderwochen beziehen sich auf 2026; entscheidend ist der Abstand zum Peak, nicht die Nummer der Woche. Der Plan setzt voraus, dass jede Aufgabe eine benannte Person hat und dass jede erledigte Aufgabe eine Messung hinterlässt, an der man sie später wiedererkennt. Ohne diese beiden Bedingungen bleibt ein Plan eine Absichtserklärung.

1. KW 38 bis 39, Bestandsaufnahme: Vorjahreskurve aus der Auswertung ziehen, Spitzenstunden und Spitzentage notieren, alle Adressen inventarisieren, die Umsatz tragen, und je Adresse festhalten, welche Prüfung sie heute abdeckt.
2. KW 40, Messgrundlage: Baseline für Antwortzeit und Fehlerrate je Wochenstunde erheben, Perzentile statt Mittelwerte einrichten, Schwellen an die Baseline binden.
3. KW 41, Lastprobe: Kaufweg unter erhöhter Last durchspielen, Engstellen benennen, den Rückweg auf den letzten guten Stand einmal vollständig proben und die tatsächliche Dauer notieren.
4. KW 42, Fristen: Zertifikate, Domains, Zugangsschlüssel und angekündigte Wartungsfenster prüfen; alles, was zwischen November und Januar abläuft, jetzt erneuern.
5. KW 43, Alarmkette: Bereitschaft und Vertretung festlegen, zweiten Kanal einrichten, Eskalation nach zehn Minuten setzen und die Kette einmal von der Prüfung bis zur Annahme durchmessen.
6. KW 44, Statusseite: Statusseite außerhalb der Shop-Infrastruktur einrichten, Testvorfall proben, Wartungsfenster für November und Dezember eintragen.
7. KW 45, Freeze und Intervalle: Prüfintervalle auf das Hochlastfenster umstellen, Change-Freeze in Kraft setzen, Ausnahmeweg schriftlich bekannt geben.
8. KW 46 bis 51, Betrieb: täglicher Blick auf Perzentile und Fehlerrate gegen die Vorwoche, wöchentliche Kontrolle der Fristenliste, jeder Vorfall mit Uhrzeit und Ursache protokolliert.

Nach dem Peak: was ausgewertet wird

Der Wert der Vorbereitung entsteht erst im Januar, wenn aus dem Verlauf eine Grundlage für das nächste Jahr wird. Drei Auswertungen lohnen sich. Erstens die Lastkurve in Stundenauflösung: Wann lag das tatsächliche Maximum, wie weit lag es über dem Septemberniveau, und traf es die vorbereitete Kapazität? Zweitens die Vorfallsliste mit Erkennungszeit, Zustellzeit und Annahmezeit je Ereignis: Diese drei Werte sagen mehr über die Betriebsfähigkeit als jede Verfügbarkeitszahl am Jahresende. Drittens die Antwortzeitverteilung über die Wochen: Ein langsamer Anstieg über sechs Wochen ist ein Kapazitätsthema, ein Sprung an einem einzelnen Tag ist ein Änderungsthema.

Der HDE erwartet für 2026 ein nominales Umsatzwachstum von zwei Prozent im Einzelhandel und von 4,4 Prozent im Onlinehandel; der Onlinehandel soll dabei 96,3 Milliarden Euro zum Gesamtumsatz von 697,4 Milliarden Euro beitragen (HDE). Der Onlinehandel wächst nach dieser Prognose also weiter schneller als der Handel insgesamt, und damit wächst auch der Anteil des Umsatzes, der in einem Hochlastfenster von der Technik abhängt. Wer die Auswertung im Januar schreibt, hat im September die Vorlage für den nächsten Plan. Wer sie auslässt, beginnt im nächsten Jahr wieder mit Schätzungen. Ein Blick in die Demo-Umgebung zeigt, wie Prüfungen, Fristen und Eskalationsstufen in einer Ansicht zusammenlaufen.