Status Pages for Ecommerce
A straightforward status-page workflow for online stores.
Status pages for ecommerce: make checkout, payment, and order confirmation their own components — that is where an outage costs money, not the homepage.
What this status page should answer
Ecommerce teams need status visibility around browse, cart, checkout, payment handoff, and order confirmation. Small failures can become lost revenue quickly.
- Checkout and payment handoff get their own public components.
- Order confirmation is where lost revenue becomes visible.
- Support can link the page instead of fielding the same question repeatedly.
The revenue-critical components
An ecommerce status page should be organized around the funnel, with the money-making steps as their own components. Browse and search matter, but the components that deserve the tightest monitoring and the clearest public status are checkout, payment handoff, and order confirmation — the steps where an outage is directly lost revenue rather than a cosmetic problem. Back each with a content check that confirms the real page elements render, since a checkout that returns 200 but shows an empty form is still down to a buyer. During an incident, a public page support can link ("checkout is degraded, we are working on it") cuts repeat tickets and reassures customers that you already know. Keep internal payment-service names off the page; show the step the customer is standing on.
Building the page in Sandglass
Use HTTP and content checks for storefront and checkout pages, TCP checks for critical network services where appropriate, and a public page that support can link during incidents.
- Publish a public status page that shows live monitor state for the services customers recognize.
- Back every public component with a real check so the page reflects measured availability.
- Keep internal-only checks private and route their alerts to email, Slack webhooks, or a generic webhook.
What not to publish
Avoid treating homepage uptime as proof that the store is healthy. Checkout and order confirmation deserve their own checks because that is where revenue impact concentrates.
Implementation checklist
Step 1: Name components in customer language
List the services customers recognize — website, API, checkout, dashboard — not internal subsystems.
Step 2: Attach a check to each component
Back every public component with an HTTP, content, TCP, or SSL certificate check so its state is measured, not toggled by hand.
Step 3: Decide what stays private
Keep noisy internal dependencies off the public page and route their alerts to your team channel instead.
Step 4: Publish and link it
Add the public status page link to support replies and documentation so customers can self-serve during incidents.