The Status Page Checklist: 12 Things to Have Ready Before the Next Incident

A status page that has never been exercised in anger is a rumor about preparedness. It looks fine on a quiet Tuesday. During the first real Sev-1 you discover the subscriber email never arrived, the page shares a cluster with the API that is down, and nobody can find the URL from the product error screen.

Use this as an audit list. Check each item. Fix the gaps before the next incident does it for you.

1. Custom domain configured

Your public page should live at something like status.yourdomain.com, not a random third-party subdomain customers will not trust or remember.

Failure mode. People cannot find the page, or they hesitate because the URL looks unrelated to your product.

2. Per-component status

Break the page into components customers recognize. API, Dashboard, Payments, Authentication. A single "All systems operational" toggle hides partial outages.

Failure mode. Checkout is down, the banner still says operational because "the website" loads, and support spends the incident arguing with screenshots.

3. Subscriber flow working

Confirm email subscription end to end. Confirmation message received. Unsubscribe link works. Preferences make sense.

Failure mode. You have a subscribe box that writes to a void. During the outage you "notified subscribers" and nobody got mail.

4. Historical incident log visible

Past incidents should remain listed with dates and short summaries. Hiding history reads as reputation management.

Failure mode. Customers assume every outage is being quietly erased. Trust drops even when today's update is honest.

5. Pre-written incident templates saved

Investigating, identified, monitoring, resolved. Saved copy so the first update ships in about two minutes.

Failure mode. The first public words take twenty minutes of committee editing while Twitter and support fill the silence.

6. Automatic monitor-to-status-page connection

When a monitor fails, the matching component should move without someone remembering to click through a UI under stress.

Failure mode. The API has been erroring for fifteen minutes. The status page still says operational because the only person who can edit it is on a bridge call.

7. Maintenance window capability tested

Schedule a maintenance window in staging or a low-risk component. Start it. End it. Confirm subscriber messaging if you use it.

Failure mode. First planned maintenance is also the first time you learn the tool cannot post maintenance cleanly, so you improvise on the incident page.

8. Mobile rendering verified

Open the page on a phone. Check component list, incident updates, and subscribe flow.

Failure mode. Half your audience is on mobile support threads. Your status page is a desktop table that requires sideways scrolling to read the only sentence that matters.

9. Redundant hosting confirmed

The status page must not share fate with the product it reports on. Separate hosting, separate failure domain.

Failure mode. Primary region dies. Product is down. Status page is down. Customers have no official signal, only speculation.

10. Internal status page for engineering

Keep a private view with more technical detail than the public page. Public gets customer impact. Internal gets services, owners, and sharper component cuts.

Failure mode. Engineers paste internal hostnames onto the public page, or they invent a parallel Google Doc that drifts from what customers see.

11. Subscriber notification tested end to end

Do not stop at "send succeeded" in the admin UI. Receive the email. Confirm rendering. Click through to the incident. Confirm unsubscribe still works after a real send.

Failure mode. Your ESP accepted the API call. Corporate filters ate the message. You learn that from angry customers, not from your own test inbox.

12. Status page URL in product error pages and docs

Put the link on error screens, timeout pages, and support documentation. People under stress will not invent status. as a subdomain guess.

Failure mode. Customers open a support ticket titled "is it down??" while your carefully built status page sits undiscovered.

How to run the audit

Block thirty minutes with whoever owns the status page and whoever owns on-call. Work the twelve items in order. For each one, either mark verified with a date or open a ticket with an owner. Do not leave items in a vague "we should look at that" state.

If you are setting the page up for the first time, finish items 1, 2, 5, 6, and 9 before you announce the URL publicly. A page that cannot stay up during an outage, cannot name components, and cannot ship a first update quickly will hurt more than it helps.

Re-run the full list after any tool migration, branding change, or ESP switch. Subscriber and rendering failures love to appear quietly after "small" configuration changes.

Vigiles includes public status pages with per-component status, subscriber flows, and updates driven from monitor state, which covers several of these items when configured on purpose. The checklist still matters. Features you never tested are not features you have in an incident.