Decide which function is unavailable
An unavailable checkout does not automatically mean the entire website must disappear. Before choosing a response, map the affected functions: product browsing, account access, order creation, payment return, support information and robots.txt may have different dependencies. If a product page still works, keep serving it normally; if order submission cannot safely complete, block that operation clearly and protect the customer from an ambiguous charge or duplicate order. A planned maintenance window and an unexpected database failure can use the same basic temporary-unavailability language, but their expected duration and fallbacks differ. The important decision is per route and per customer action. A site-wide switch is easier to implement yet can unnecessarily hide useful pages. Conversely, serving a polished error message with a success status tells automated clients that the request succeeded when the requested content was absent. Record which URL classes should stay available, which should return a temporary error, and which require a manual service alternative. That map guides both implementation and later recovery checks.
Match the HTTP status to the condition
RFC 9110 defines 503 Service Unavailable for a server temporarily unable to handle a request, such as overload or maintenance, and allows Retry-After to suggest when service may be restored. Use a genuine 503 response for temporarily unavailable pages or operations. Do not return 200 with an “under maintenance” body when the requested page did not load; that is a misleading success. A permanently removed resource is a different decision, and a client making too many requests is a 429 case rather than an ordinary site outage. Avoid replacing every failure with a redirect to the home page, because that hides the failing URL and prevents clients from recognising the problem. The application, reverse proxy and CDN must agree on the outward status. A framework might render a maintenance component while an upstream layer changes the code, so verify the actual network response, not only the browser appearance. If an API is affected, preserve its documented machine-readable error format where possible.
Use Retry-After only with an honest estimate
The Retry-After header can hold a delay in seconds or an HTTP date under RFC 9110. Google’s temporary-disable guidance recommends a best-effort date or duration for a 503 response. During scheduled maintenance with a credible end time, a conservative estimate can help clients plan. During an unknown incident, do not present a precise promise the team cannot support; a short review interval may be more honest if the service will reassess then. The header is a hint to automated clients, not a guarantee that the site will work at that exact second. The human page should say when information will next be updated or where support can be reached, distinguishing that from a confirmed restoration time. Test that a proxy does not strip the header and that a cached stale error does not survive after recovery. A retry time that has already passed, or an absolute date in the wrong time zone, can cause confusing client behaviour. Keep the operational owner of the estimate explicit.
Serve a light page that can survive the fault
A maintenance page that requires the same failing database, sign-in service or remote script may fail exactly when it is needed. Google Search Central advises a static HTML page with minimal off-page resources for a temporary site pause. Design a short page that can be served by a stable edge or web server path, with accessible headings, readable text, a useful contact route and no false claim that an order was accepted. If some browsing remains available, link to those working functions. If the support address is itself on the affected domain, check that it remains usable during the outage. Do not display a countdown unless someone can keep its estimate current. For order flows, preserve server-side evidence of any accepted transaction and make a separate status-check route or support process available if practical. The page is a safety aid, not a substitute for resolving the underlying incident. Test it by deliberately taking a dependency out of service in a controlled environment.
Treat crawlers as clients of the same truth
Google Search Central says temporary 503 responses can signal a short site pause, and warns against using 403, 404, 410 or noindex to represent a temporary closure. It also advises keeping robots.txt available rather than returning 503 for that file. The guidance is limited: prolonged server errors can reduce crawling and eventually affect indexing, so 503 is not a long-term publishing strategy. A brief failure should not trigger a site-wide removal request or a permanent block. Test what a crawler can actually fetch through the public edge, including the HTTP status of product URLs and robots.txt, without assuming that a browser’s rendered message is enough. Search guidance does not override the need to keep customer transactions safe. If checkout is down but information pages work, serving those pages normally may preserve useful customer access and reduce unnecessary search disruption. Monitor crawling and index reports after a material outage, but interpret them alongside the real outage duration and affected URL set.
Walk through a checkout dependency failure
Consider a small retailer whose payment integration stops responding while product pages and the support page still work. The retailer disables new payment attempts and presents a clear temporary-unavailability response for the payment step. Product pages continue returning their normal content and status, while the checkout action avoids claiming success. If an earlier payment request may already have reached the provider, the customer sees a neutral pending instruction and a way to check the order, rather than a prompt to pay again immediately. The incident owner chooses an honest Retry-After policy for affected responses and updates the human guidance separately. This is a hypothetical exercise, not evidence of a particular merchant’s outage. It shows why a single home-page maintenance switch would discard useful browsing and why an unqualified “failed” message could cause duplicate payment attempts. The success condition is that a customer can distinguish an accepted order, a pending outcome and a request that was definitely not accepted.
Check the outward response through every layer
An application may be configured correctly while a CDN caches its 503 body as if it were normal content, an edge rule rewrites the status to 200, or an API gateway returns a different error shape. Test from outside the private network with a real GET for representative URLs. Record status, headers, body and cache behaviour for a healthy information page, an affected HTML page, an affected API operation and robots.txt. A HEAD request is useful but should not be the only test, because some stacks handle it differently from GET. Follow redirects deliberately so a test does not mistake a successful destination for a healthy original operation. Check both anonymous and signed-in paths where relevant, while keeping test accounts and customer data out of public logs. A service worker or browser cache may show an older page even when the network correctly returns 503, so test a fresh session too. Keep this acceptance matrix short enough to run during a real incident.
Prove the site has recovered, route by route
Recovery is more than removing the maintenance banner. First confirm the failed dependency is healthy, then verify a representative read, safe test write and any payment or order outcome lookup through the public route. The previously affected URL should again return its intended content and status, while the fallback 503 and temporary Retry-After disappear. Clear or expire any cached error response in the layers that served it; otherwise some customers can remain stuck after the origin recovers. Re-enable real transactions only when the team can reconcile pending attempts and observe new ones completing. Review logs for affected customer actions and provide support with a bounded list of cases needing follow-up, without assuming every failed page view was an abandoned order. Finally, monitor error rate and status codes for the same URL set that failed. This closes the loop between the declared outage scope and the proof of service restoration.
Rehearse before the next incident
Give the maintenance switch a named owner, an activation test and a rollback test. Store the route matrix and example responses beside the operational runbook, with a clear way to update customer-facing language. During a rehearsal, simulate a payment dependency failure and a broader application failure separately; they should not produce identical effects on every URL. Verify that support can still be contacted, that a customer cannot accidentally submit a transaction twice, and that monitoring sees the same statuses a public client sees. After the exercise, fix any mismatch between the application, proxy, CDN and browser. Keep a record of the time the switch was enabled, the URL scope, the observed status and the time normal responses returned. Those are operational observations from a real rehearsal, unlike a generic promise that downtime will be harmless. A small firm does not need an elaborate status platform to answer this question, but it does need a truthful response path that can be executed under pressure.
Before accepting the change
- Check the actual public HTTP status for affected URLs, not only the displayed page.
- Keep useful pages and robots.txt available when their dependencies work.
- Verify pending transactions and cached errors before declaring recovery.
