Q4 Traffic Peaks: Site Readiness Before Peak Season

Why the fourth quarter is its own operating window

An outage does not cost the same everywhere. It costs whatever would otherwise have happened in that same span of time, and that reference point shifts towards the end of the year. For December 2025 the Federal Statistical Office reports revenue growth of 3.2 percent in real terms over the same month a year earlier, 3.5 percent in nominal terms (Destatis). Across the whole of 2025 the real increase was 2.7 percent (Destatis). December therefore pulls harder than the year that contains it. Add the peculiarity of this window: someone who cannot complete a basket on 20 December will typically not come back on the 27th, but buy elsewhere or not at all. How such a loss can be quantified at all is described in the article on calculating the cost of website downtime.

Two numbers frame the size of the window. The German Retail Federation forecast retail revenue of 126.2 billion euros for November and December 2025 (HDE), and those same two months account for 18.5 percent of the entire annual figure (HDE). One sixth of the year therefore carries almost one fifth of the result. For the technology behind a shop this means that the same availability figure means something different in December than it does in July. A month at 99.5 percent availability allows around 3.7 hours of downtime, half a percent of 744 hours. In July that is an annoyance. In the week before Christmas it is a number that shows up in the annual review.

• 126.2 billion euros in retail revenue were forecast by the HDE for November and December 2025, up 1.5 percent on the previous year in nominal terms and flat once adjusted for prices (HDE).
• 18.5 percent of annual revenue falls into those two months by the same calculation (HDE).
• 22.2 billion euros of that belongs to online retail, up 3.3 percent in nominal terms on 2024 (HDE).
• 5.8 billion euros were expected by the HDE for Black Friday and Cyber Monday 2025 alone, around 1.6 billion euros of it as Christmas shopping (HDE).
• 3.2 percent more revenue in real terms than in the same month a year earlier was reported by the Federal Statistical Office for December 2025 (Destatis).
• 4.4 percent nominal growth is expected by the HDE for online retail in 2026, against two percent for retail as a whole (HDE).

These figures are forecasts and survey results, not till receipts. The HDE bases its Christmas forecast on a survey of 300 retail companies and a consumer survey by the Handelsblatt Research Institute covering more than 2,000 people (HDE); the 2026 annual forecast rests on a survey of just under 600 retail companies (HDE). They are therefore useful for orders of magnitude, not for planning individual hours. For technical preparation the order of magnitude is enough: it says that two months carry close to a fifth, and it says when. Everything else comes from your own measurements of previous years, and those are exactly what should be pulled from the analytics now, while there is still time to change something.

The load curve does not start on Black Friday

Anyone who pins the peak to a single day is planning against the actual shape of the curve. In 2025 Black Friday fell on 28 November and Cyber Monday on 1 December (HDE). The HDE expected 5.8 billion euros in revenue for those promotional days, around 1.6 billion euros of it Christmas shopping (HDE); 54 percent of respondents said they also use Black Friday for Christmas shopping, and 42 percent said the same of Cyber Monday (HDE, survey by IFH Cologne among more than 1,000 online shoppers in October 2025). That pulls demand forward without emptying December. The result is not a spike but a plateau: raised load from the second week of November, a maximum around Black Week, a second rise around the second and third Sundays of Advent, then a decline set by the last promised delivery date.

For operations this plateau has an awkward property: it lasts longer than any maintenance window you could keep clear for it. An outage on Black Friday is visible and gets worked on immediately. The quiet degradations over weeks weigh heavier: a database query that grows from 80 to 900 milliseconds under load, an image directory slowly filling the disk, a payment service that runs into a timeout on every twentieth call. None of that produces an error page, and none of it shows up in an availability figure of 99.9 percent. Such trends live in the response time distribution and in the error rate, not in a traffic-light state.

Change freeze: what is frozen and what is not

A change freeze is an agreement, not a technical lock. It sets out from which date which kind of change needs an explicit approval. The purpose is not to slow the team down but to reduce the number of variables changing at once: if three things are different during the peak phase, finding the cause of an incident takes several times as long. A staged freeze works well. From mid-October only changes with a rehearsed way back go live, from calendar week 45 only fixes with a named risk, and from the start of Black Week the tightest rules apply. After the peak the freeze is lifted in the same order.

1. Frozen: layout and theme changes, new payment or shipping methods, changes to category structure and URLs, extension updates without a security reason, switching the PHP or database version.
2. Possible with approval: price and stock changes, editorial content, promotional banners and configuration values that can be reset without a fresh release.
3. Exempt from the freeze: security updates for a known, exploited vulnerability, certificate renewals, deadline matters such as an expiring domain, and anything that ends a running incident.
4. Allowed without asking: rolling back to the last known good state.
5. Written down: who may approve, through which channel approval is requested, and how long the team waits for an answer before the fallback decision applies.

The freeze needs a second element to hold: a dependable way back. Before 1 November there should have been one rehearsal of how long a return to the previous state actually takes, including database migrations, cache warm-up and rebuilding the search indexes. What counts is the duration on the clock, not the one in the plan. Anyone who first rehearses during an incident measures it under the worst possible conditions. The way back also includes the question of what happens to orders created between release and rollback. For the cache layers that like to keep serving old pages after such a switch, the article on finding stale pages after a deploy is the relevant one.

Check intervals for the peak window

The check interval determines detection time, and detection time determines the damage. With a five-minute interval an average of two and a half minutes and at worst five minutes pass before an outage is noticed at all; on top of that come confirmation from a second location and the delivery of the notification. A one-minute interval shortens the average to thirty seconds. What that means for the choice, and where tighter intervals turn into false alerts, is set out in the article on choosing an uptime check interval. For the fourth quarter the rule is plain: whatever carries revenue is checked more tightly, and the switch happens before the freeze, not during Black Week.

Two rows of this table deserve a reason. The hourly check of cart and checkout is the most reliable way to notice a fault that only affects signed-in customers or only appears at the third step: the home page answers with status code 200 and yet no order goes through. The approach is described in the article on monitoring the login flow and testing checkout. The second row is the certificate threshold: 45 days sounds generous, but it covers exactly the case where a renewal falls inside the freeze and is therefore only handled after Black Week.

More than reachable: what gets measured in the fourth quarter

A status light answers a question that is too coarse for the fourth quarter. Between reachable and down lies the range in which most lost revenue is created: pages that take eleven seconds to build, baskets that come back empty on submit, a payment service that rejects every twentieth request. Checks therefore work on several levels and come together on the same time axis, so that a rise in response time and a spike in the error rate read as one event rather than two unrelated notifications.

What the page shows from outside and what stays invisible from inside belongs in the same picture. If an upstream cache is still serving while the origin server already rejects requests, external measurement looks healthy and orders break off anyway; that case is described in the article on monitoring the origin behind a CDN. The same applies to where traffic comes from: if the shop runs behind a load balancer, reading the forwarded address correctly decides whether a load spike consists of real customers or of a single tool, as shown in the article on handling X-Forwarded-For correctly. Which checks a shop needs permanently is summarised in the article on e-commerce monitoring.

Response time under load: percentiles instead of averages

The average response time is the metric that hides a load spike most reliably. Ten measurements between 180 and 1,450 milliseconds give an average of 443.5 milliseconds. That number describes none of the ten calls: eight were well below it, two well above, and those two are the customers who leave. The 95th percentile of the same series sits at 1,450 milliseconds and names the edge at which the experience tips over. The thresholds of the Core Web Vitals are tied to a percentile for the same reason: the metric there is the 75th percentile of page loads, segmented across mobile and desktop devices (web.dev).

// Percentile from a series: sort, find the rank, read the value
function percentile(values, p) {
  const series = [...values].sort((a, b) => a - b);
  if (series.length === 0) return null;   // no measurement, not 0
  const rank = Math.ceil((p / 100) * series.length) - 1;
  return series[Math.min(Math.max(rank, 0), series.length - 1)];
}

// Ten response times of a checkout page in milliseconds
const responseTimes = [180, 190, 205, 210, 230, 260, 310, 420, 980, 1450];

const mean = responseTimes.reduce((a, b) => a + b, 0) / responseTimes.length;
console.log(mean);                          // 443.5
console.log(percentile(responseTimes, 50)); // 230
console.log(percentile(responseTimes, 95)); // 1450

For the fourth quarter the absolute number matters less than its movement. A checkout sitting at 600 milliseconds in the 95th percentile in October and at 1,900 in mid-November has a problem, even if no fixed limit has been crossed. That is why the threshold in the peak window belongs to a baseline rather than to a fixed number: measurement runs against your own previous week at the same hour of the week. For orienting the targets the Core Web Vitals remain useful, naming 2.5 seconds for the largest contentful paint, 200 milliseconds for the response to interactions and a value of 0.1 for layout stability (web.dev). How percentiles are formed and read cleanly is covered in the article on p95 and p99 instead of averages.

A load spike is rarely survived because more computing power was standing by. It is survived because somebody noticed the degradation two weeks earlier.

— XICTRAQ

Deadlines that land in the middle of the peak window

Certificates do not expire by calendar year but by issue date, and their permitted lifetime has become considerably shorter. Under the Baseline Requirements of the CA/Browser Forum, certificates issued on or after 15 March 2026 and before 15 March 2027 must not have a validity period greater than 200 days; no more than 199 days is recommended (CA/Browser Forum). A certificate issued in April 2026 therefore expires in October or November 2026, right in the middle of the peak window. From 15 March 2027 the upper limit drops to 100 days, and from 15 March 2029 to 47 days (CA/Browser Forum). Anyone who has renewed by hand once a year until now runs into a scheduling problem for the first time in the fourth quarter of 2026.

• Check the expiry date of all certificates, including intermediate certificates and certificates on subdomains, and set the warning threshold to 45 days.
• Test automatic renewal by renewing a certificate early; a renewal job that has been failing silently for months otherwise only surfaces on the expiry date.
• Check the expiry dates of domains and redirect domains, along with the payment details stored at the registrar.
• Note the validity of access keys for payment and shipping services; expired keys produce errors that look like load problems.
• Ask for the announced maintenance windows of the services you embed and enter them in the same calendar as your own.
• Check recipient lists and phone numbers used for alerting; an address nobody has watched since the summer otherwise surfaces during an incident.

Alerting, escalation and the way back

For operations an outage does not begin when it happens but when somebody acknowledges it. Between those two moments lie detection time, delivery time and response time. In the peak window response time is the part most often underestimated: the alert goes out at half past eight in the evening to an address nobody is reading at that hour. Preparation therefore includes a named on-call person with a deputy, a second channel next to email, and an escalation level that fires after ten minutes without acknowledgement. Building such a chain is described in the article on incident management and escalation.

The first call in the example shows what matters here: status code 503 signals under RFC 9110 that a server cannot handle a request because of a temporary overload or scheduled maintenance, and the server can use the Retry-After header field to state how long a client ought to wait before a follow-up request (RFC 9110). In the peak window that is more than a formality: for search engines and for your own analysis it separates a planned refusal from a collapse. A maintenance page answering with status code 200, by contrast, is treated as valid content. How maintenance windows are set without flooding the alert chain is covered in the article on maintenance windows in monitoring.

Status page and maintenance windows before the peak

In the fourth quarter the number of enquiries reaching customer service during a fault rises along with the load. A public status page takes some of that in advance by naming the state before anyone asks. It should be set up before the freeze, rehearsed with a test incident and linked in the footer. The separation matters: the status page does not belong on the same infrastructure as the shop, otherwise it is unreachable at exactly the moment it is needed. How such a page is built and worded is described in the article on setting up a status page.

Planned maintenance windows belong in the same view and the same calendar week as the freeze plan. A window recorded in the monitoring suppresses alerts for the period concerned and at the same time appears as an announced entry on the status page. That removes a common reason for alert fatigue in December: a chain of notifications that are all already known. For the fourth quarter it makes sense to place maintenance windows in the early morning hours, limit them to 30 minutes, and record in advance for each window when it counts as failed and the way back is taken. Status page and reports can be tied to the same data for that purpose.

The schedule from mid-September to Black Week

The preceding sections turn into a calendar. The calendar weeks refer to 2026; what matters is the distance to the peak, not the number of the week. The plan assumes that every task has a named owner and that every completed task leaves a measurement behind by which it can later be recognised. Without those two conditions a plan remains a statement of intent.

1. Weeks 38 to 39, inventory: pull last year's curve from the analytics, note peak hours and peak days, inventory every URL that carries revenue, and record for each one which check covers it today.
2. Week 40, measurement basis: collect a baseline for response time and error rate per hour of the week, set up percentiles instead of averages, tie thresholds to the baseline.
3. Week 41, load rehearsal: run the buying path under raised load, name the bottlenecks, rehearse the way back to the last good state once in full and note the actual duration.
4. Week 42, deadlines: check certificates, domains, access keys and announced maintenance windows; renew now anything that expires between November and January.
5. Week 43, alert chain: define on-call and deputy, set up the second channel, set escalation to ten minutes and measure the chain once from check to acknowledgement.
6. Week 44, status page: set up the status page outside the shop infrastructure, rehearse a test incident, enter maintenance windows for November and December.
7. Week 45, freeze and intervals: switch check intervals to the peak window, put the change freeze into force, announce the exception path in writing.
8. Weeks 46 to 51, operations: a daily look at percentiles and error rate against the previous week, a weekly review of the deadline list, every incident logged with time and cause.

After the peak: what gets reviewed

The value of the preparation only appears in January, when the record turns into a basis for the next year. Three reviews are worth the effort. First the load curve at hourly resolution: when was the actual maximum, how far above the September level did it sit, and did it meet the prepared capacity? Second the incident list with detection time, delivery time and acknowledgement time per event: those three values say more about operational readiness than any availability figure at the end of the year. Third the response time distribution across the weeks: a slow rise over six weeks is a capacity matter, a jump on a single day is a change matter.

For 2026 the HDE expects nominal revenue growth of two percent in retail and 4.4 percent in online retail; online retail is forecast to contribute 96.3 billion euros to a total of 697.4 billion euros (HDE). By that forecast online retail keeps growing faster than retail as a whole, and with it grows the share of revenue that depends on technology during a peak window. Whoever writes the review in January has the template for the next plan by September. Whoever skips it starts the next year with estimates again. A look at the demo environment shows how checks, deadlines and escalation levels come together in one view.