In short and in plain language
If the checkout of your shop fails, customers have questions. Without an answer, some order twice. Others write to support.
A status page informs customers during a problem. It must also work when the shop is down. So it runs apart from the shop.
The article shows how to build such a page. It also shows which messages to write and in what order.
We take on monitoring, the status page and the messages as one package.
When a shop checkout fails, the operator faces a technical problem – the customer faces a question. For 57 percent of surveyed operators, the most recent major outage cost more than 100,000 US dollars, and for one in five the damage exceeded one million US dollars (Uptime Institute). Part of that cost does not arise in the technology but in the silence before it: orders get placed twice, support receives the same question a hundred times, and anyone who finds no answer buys elsewhere. A status page is one of the cheapest remedies – provided it does not run on the same machine as the shop. This article describes what belongs on such a page, how it is wired up technically, and which updates go out in which order.
Key takeaways
- The status page does not belong on the infrastructure it reports about. Over nine years, roughly two thirds of publicly reported outages were attributed to third-party IT and data center service providers (Uptime Institute).
- In maintenance mode the shop answers with 503, not 200 or 404: the code indicates temporary overload or scheduled maintenance (IETF, RFC 9110). The Retry-After response header states the expected delay alongside it.
- Three updates carry an incident: a first update without a cause, a progress update at the promised time, and a closing update with follow-up work. Reliable beats detailed – the progress update goes out even when there is nothing new.
- If personal data is affected, a second clock starts: notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours (Art. 33 GDPR), and notification of data subjects in clear and plain language (Art. 34 GDPR).
- Any recovery time you state is a planning figure, not a forecast. BSI Standard 200-4 measures the required recovery time from the declaration of the emergency to the required commissioning of the fallback solution (BSI).
Why silence costs more than the outage
An outage writes two invoices. The first one is technical and is measured in minutes. The second one forms in the customer's mind and keeps running long after the technology is working again. For 57 percent of surveyed operators, the most recent major outage cost more than 100,000 US dollars, and for one in five the damage exceeded one million US dollars (Uptime Institute). In the same analysis, around one in ten say their last outage had serious or severe impacts (Uptime Institute, Outage Analysis 2026). These figures come from data center operations, but the mechanics in retail are identical: anyone who does not know whether their order went through places it again, calls, writes a message – and creates work that ties up staff for days after the outage.
Support is the most expensive channel in this. A 90-minute disruption during an evening peak produces the same question in every inbox, every chat window and on every phone line, and every answer is typed individually. A status page inverts that ratio: it answers the question once, in one place, referenced by support, newsletters, social profiles and the shop's own error page. The effort shifts from answering a hundred times to writing three times. The prerequisite is that the disruption is noticed at all before the first customer calls – that is the job of continuous availability monitoring, not of the status page itself.
A status page on the same machine is not a status page
What belongs on a status page – and what does not
A status page is neither a blog nor a ticket system. It answers four questions in this order: what is affected, since when, what is being done, and when the next message arrives. Everything else is ballast. A common mistake is stating a cause in the first update. At that point it is typically a guess, it has to be corrected later, and the correction costs more trust than the initial silence about the reason. The first update therefore names the effect, not the cause – and it names it in the customer's language, not in the language of operations.
The most important element is the timestamp. A page that says work is under way without giving a time cannot be told apart from a frozen page, and visitors assume the worse of the two. Every update therefore carries a date and a time including the time zone, and the header of the page additionally carries the time of the last refresh. Anyone pulling that time automatically from a system should first check whether that system answers at all during an outage; setting up your own availability measurement provides a data source that is independent enough.
| Element of the page | Which question it answers | Typical mistake | How to verify it |
|---|---|---|---|
| Status banner at the top | Is the shop usable right now? | Only two states: working or not working | A third state for degraded operation exists |
| Timestamp of the refresh | How old is this information? | Time without a time zone, or no time at all | The time zone is in the text, cross-checked against a second clock |
| System rows | What exactly is affected? | One single overall status for everything | Checkout and payment are shown separately |
| Promise of the next update | When will I learn more? | Open-ended text without a fixed time | The next time is stated in every update |
| Guidance for customers | What should I do now? | Missing, so orders get placed repeatedly | One sentence on duplicate orders and pending payments |
| Contact route | Where do I ask? | A link to a form inside the failed shop | The route sits outside the affected application |
What does not belong on the page is just as clearly defined: names of individual staff, internal system designations, blame directed at service providers, and anything that allows conclusions about customer data. Number games with availability figures are equally out of place – quoting an annual percentage during a live outage looks like an attempt to talk the incident down. How expensive an outage actually becomes can be calculated against lost revenue later and in peace; during the disruption it is beside the point.
The four system rows: shop, checkout, payment, search
A single overall status is worth little to the customer because it answers the wrong question. Someone tracking a shipment needs different information than someone about to pay. Four rows typically cover retail: the shop itself, the checkout, the payment connection, and search together with the catalogue. Each row carries its own state and its own history. That history is not decoration. It shows whether this is a one-off hiccup or the third event of the day, and it takes the edge off the recurring question about frequency.
Row 1: shop reachable
What gets measured is the retrieval of a real category page with status code and response time, not a ping against the home page. Otherwise a shop serving a cached home page while the catalogue is down still counts as available.
Row 2: checkout
The checkout needs its own row because it carries the most expensive minute of the outage. What gets checked is the path up to the payment selection, not merely whether the address responds.
Row 3: payment connection
In practice this row usually breaks outside your own house. It is tracked separately so the update can say that the shop is running and only one payment route is unavailable.
Row 4: search and catalogue
A failed search produces no error status but empty result pages. What gets measured is therefore a search term with a known hit, not the reachability of the search service.
History per hour
One dot per hour across 24 hours is dense enough for the day and coarse enough to stay readable. Finer resolution produces a chart that nobody reads during an incident.
Separate operation
Host, DNS zone and certificate of the status page sit outside the shop environment. Without that separation the page only measures whether it is reachable itself.
The payment row deserves particular attention because in practice it rarely breaks in your own house. Over nine years, roughly two thirds of publicly reported outages were attributed to third-party IT and data center service providers (Uptime Institute). For the status page that means an outage you did not cause yourself still has to be reported – with a note that the cause lies outside, and without naming the provider. How dependencies on third-party providers can be defused beforehand is a topic for calm operations, not for the incident.
The technical foundation: 503 and Retry-After
While the shop is not answering, the web server decides what visitors and search engines see. The appropriate status code is 503. It 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 (IETF, RFC 9110). The difference to the two widespread mistakes is substantial. An error page returning status 200 tells the search engine this content is exactly as intended. A 404 tells it the address no longer exists. Both statements outlive the outage and keep working afterwards.
The 503 belongs together with the Retry-After response header. It carries either a date or a number of seconds and tells the recipient how long the service is expected to be unavailable (IETF, RFC 9110). It stays invisible to visitors; for crawlers it is the basis for deciding when to try again. For planned work the value is easy to set, because the maintenance window is scheduled in advance anyway. For unplanned disruptions you set a conservative value and update it with the next progress update.
# Maintenance and incident mode: the shop answers with 503,
# the status page runs on a different host and stays untouched.
map $request_uri $maintenance {
default 1;
~^/status-notice/ 0; # local notice page stays reachable
~^/assets/notice/ 0;
}
server {
# ... shop configuration ...
if ($maintenance) {
return 503;
}
error_page 503 @notice;
location @notice {
root /srv/notice;
rewrite ^ /notice.html break;
add_header Retry-After 1800 always;
add_header Cache-Control "no-store" always;
}
}
For search engines the status code has measurable consequences. Server errors in the 5xx class and the code 429 make Google's crawlers slow down crawling temporarily; addresses that are already indexed stay in the index for the time being and are only removed later (Google crawling infrastructure). Once the server answers with 2xx again, Google gradually increases the crawl rate (Google crawling infrastructure). For a disruption lasting hours this has no consequences. Staying in maintenance mode for days, however, costs visibility no matter how well the status page is worded. Such states are spotted early by anyone keeping an eye on logs and alerting.
An older note from Google's Search Central blog still applies: planned downtime that is not clearly marked as such can negatively affect a website's reputation (Google Search Central 2011). The opposite direction matters just as much. The 503 is not a permanent state: its long-lasting use can be taken as a sign that an address is permanently unavailable and may lead to removal from the index (Google Search Central 2011). Whoever activates maintenance mode should schedule the reminder to switch it off in the same work step.
The update trail: first update, progress update, closing update
Three updates carry a normal incident. The first goes out as soon as the disruption is confirmed and states the effect only: which system is affected, since when, and when the next message arrives. It contains neither a cause nor a time of resolution. The progress update follows at the announced time – even when there is nothing new. That case is the most important one: an update stating that nothing has changed and that the next one follows in thirty minutes costs half a minute of work and replaces a hundred enquiries.
The third update closes the incident. It states the period, the effect and the follow-up work and – at this point, not before – the cause, as far as it has been established. Customers with partially placed orders get a concrete instruction here: try again, wait, or contact support. Anyone with an agreed response time for emergencies ties the update cadence to it instead of negotiating it during the incident. The text blocks for this are written during calm operations and stored where they are reachable without the shop.
Three updates, three different jobs
When data is affected: deadlines and language
A disruption is not automatically a data protection incident, but the transition is fluid. The regulation requires the controller to implement measures ensuring the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services (Art. 32 GDPR), and explicitly the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident (Art. 32 GDPR). Availability is therefore not a matter of convenience but part of the technical and organisational measures.
If the disruption involves a breach of personal data protection, a second clock starts. Notification to the supervisory authority is made without undue delay and, where feasible, not later than 72 hours after having become aware of the breach (Art. 33 GDPR). Where the breach is likely to result in a high risk to the rights and freedoms of natural persons, those persons are informed without undue delay, and in clear and plain language (Art. 34 GDPR). This notification is something other than the status update and does not belong in the same block library – but it does belong in the same emergency plan, together with the question of whose access has to be revoked during an incident.
- Run the status page on its own host, in its own DNS zone and without any dependency on the shop database
- Prepare three text blocks: first update, progress update, closing update – each with placeholders for system, period and next time
- Fix the cadence and state it in the first update instead of negotiating it during the incident
- Set up maintenance mode with status 503 and Retry-After, and exempt the path of the notice page from the block
- Keep the reporting route for data protection incidents separate, with the deadlines from Art. 33 and Art. 34 GDPR
- Provide a contact route outside the shop so that enquiries do not depend on the failed system
- Archive timestamps, updates and follow-up work after every incident so the next estimate rests on measured values
Recovery: which time the status page actually states
The question of when it will work again has a technical name. BSI Standard 200-4 calls the required recovery time RTO and describes it as follows: the RTO covers the period from the declaration of the emergency to the point of the required commissioning of the business continuity solution (BSI). That is a planning figure from normal operations, not a forecast for the running incident. Anyone stating it on the status page should have measured it beforehand against a rehearsed restore – otherwise a planning figure turns into a promise the incident typically fails to keep.
The same standard also describes what external communication is for: various interest groups are directly or indirectly involved in every emergency scenario (BSI), and the standard names controlling the communication in order to minimise reputational damage as the primary objective (BSI). Translated into retail: the status page is the place where your own account of events is created, before others write it in review portals and social networks. Staying silent leaves the interpretation to those who are loudest.
Restraint pays off in the wording. A statement such as expected around 15:30 is information; no later than 15:30 is a promise that costs nothing while it holds and a great deal when it breaks. It therefore makes sense to commit firmly to the next update time and to mark the recovery time as an estimate. Incidents around clock changes add another source of error, because timestamps and scheduled jobs can drift apart; that is a topic of its own and has to be re-checked every year at the switch from summer to winter time.
Testing the status page before it is needed
A status page that is opened for the first time during a real incident is a promise without cover. The test consists of two parts. The first checks reachability under adverse conditions: the shop is deliberately put into maintenance mode, and from a network outside your own data center you check whether the status page answers, which status it returns and whether Retry-After is set. The second part checks the route to it. Does the shop's error page show the link? Does support know the address? Is it in the footer of the newsletter template?
This test belongs in the same cycle as the restore test from your backups. A quarterly appointment is typically sufficient, as long as it actually takes place and is documented. Anyone maintaining an emergency plan for the worst case anyway can attach the status page check to the same list; a separate process for it rarely pays off. What matters is that the test approaches from outside: seen from your own network, almost every separation looks clean.
The alert in the example is the classic mistake: the status page is separated, but its contact form leads back into the failed shop. Such feedback loops appear in almost every first version – in the image path, in the font, in the consent banner, in the counting pixel. Every external dependency of the status page is one dependency too many; when in doubt the page is delivered without scripts and with embedded fonts. Anyone needing support during a running incident finds it in emergency support.
What the maintenance contract makes of this
A status page is quick to build and slow to maintain. The work does not sit in the HTML but in the readiness behind it: somebody has to notice the disruption, word the first update within minutes, post the progress update at the announced time and write the closing update, even when the incident ends at 23:40. At exactly this point a status page is better placed in a maintenance contract with on-call cover than in the responsibility of a single person who also takes holidays.
In practice the status page hangs on the same chain as the monitoring: the measurement detects the outage, the on-call staff confirm it, and the same staff post the update. Without that coupling a common state arises – a well-maintained status page that shows every system as available for two hours during an incident, because switching it over was forgotten in the rush. Which building blocks belong together is set out in the overview of services.
The timestamp on a status page says more about the organisation behind it than any availability figure in the annual report.
Getting started in small steps
Getting started needs no dedicated application. A single HTML file on a host that has nothing to do with the shop covers most of the benefit: status banner, four rows, timestamp, three updates below. It is maintained by hand at first, and in the first year that is an advantage, because every change stays a deliberate decision. Automation only pays off once the reporting discipline is in place – an automatically set traffic light is only as reliable as the measurement behind it.
The second step is the wiring: the shop's error page, the support signature, the newsletter footer and social profiles all point to the same address. The third step is the test under load. Only after that is it worth asking about automatically set states, and then first where the measurement already runs cleanly – for example in monitoring of checkout and transactions, which makes the most expensive part of the outage visible first.
Think of the status page and on-call cover together
Sources and studies
Related Articles
Disaster Recovery: Restoring Your Shop After an Incident
Disaster recovery for online shops: a DR plan, tested restores and defined RTO and RPO targets – going beyond plain backups, explained step by step.
Shop Server Logs: How Long IP Addresses May Be Stored
How long may IP addresses stay in server logs? What the GDPR requires, what the five weeks from the BfDI mean, and how rotation, truncation and backups fit in.
WordPress security updates: what old branches still get
WordPress 7.1.2 closed a critical flaw and the fix was backported to 4.7 as a courtesy. What older branches receive, what they do not, and when to move up.