Your Incident Page Should Exist Before the Incident

When payments stop, forms fail, or a customer portal becomes unavailable, the technical problem is only half the incident. Customers also need to know whether the business is aware, what is affected, and when they should expect another update. Inventing that communication process during an outage adds delay and avoidable confusion.

An incident page does not need enterprise ceremony. A small organization needs a dependable place for updates, prepared message states, and a named person who can publish accurate information while engineers investigate. Those decisions are easiest to make before anything is broken.

Decide what counts as an incident

Not every defect belongs on a public status page. Define incidents by customer impact: inability to pay, log in, submit an enquiry, receive a promised message, access purchased material, or synchronize critical data. A cosmetic issue can remain in the normal support queue unless it blocks a key task.

Severity should reflect scope and consequence, not how loudly one person reports the problem. A failure affecting every checkout is different from an integration delay for one account. Written levels help the team choose the right audience, cadence, and escalation path.

Choose channels that survive the failure

A status page hosted inside the failing application may disappear with it. Use an independently hosted service or a simple external page when availability matters. Decide whether updates are public, customer-only, or both, and make the link easy to find from support documentation and confirmation emails.

Direct email or in-app messages may be appropriate for affected accounts, but avoid making support agents copy inconsistent explanations. One canonical update should feed every channel so customers do not receive competing versions of the event.

Prepare four message states

Most incidents can be explained through four states:

1. Investigating: confirm the observed symptom and affected service.
2. Identified: describe the known component or cause without overstating certainty.
3. Monitoring: explain the mitigation and what the team is watching.
4. Resolved: state when normal service returned and whether follow-up is required.

Each update should include a timestamp and the next expected update time. If there is no new technical information, say the investigation continues. Silence encourages customers to retry, open duplicate tickets, or assume nobody is working on the issue.

Write for impact, not internal drama

Customers usually need the affected function, a safe workaround, and a realistic expectation. They do not need raw logs, speculative blame, or a play-by-play of every failed hypothesis. Translate internal component names into the task the customer recognizes, such as card payments or contact-form delivery.

Avoid declaring data safe until the team has verified it. Likewise, do not promise a recovery time simply to make an update sound reassuring. A bounded statement—another update in thirty minutes—is more trustworthy than an unsupported fix estimate.

Assign authority before urgency arrives

Name the incident lead, technical investigator, and communications owner. In a small team one person may hold two roles, but someone still needs authority to approve public wording. Keep customer contact lists, service owners, vendor escalation details, and status-page credentials accessible without relying on the affected system.

Run a short exercise using a plausible event such as failed payment webhooks. Confirm who notices, who opens the incident, who posts the first message, and how support learns the approved response. A ten-minute rehearsal exposes missing permissions quickly.

Close the loop after service returns

Resolution is not the end of the work. Review detection time, customer impact, update cadence, mitigation, and any confusing handoff. Capture a small number of corrective actions with owners and dates; a long retrospective without follow-through does not improve reliability.

A good incident process does not prevent every failure. It prevents confusion from becoming a second failure. Draft the investigating message and verify status-page access now, while the team can discuss wording without an outage clock running.

Use a timeline during the response

Keep an internal incident timeline separate from the public message. Record detection, confirmation, decisions, vendor contacts, mitigations, customer updates, and recovery evidence with timestamps. This gives the incident lead a shared picture and prevents an incoming team member from restarting investigations already completed.

The timeline also supports a factual retrospective. It can show that monitoring detected the failure late, that approval delayed the first message, or that a mitigation was attempted twice. Preserve relevant logs and screenshots, but restrict sensitive technical or customer data to the people who need it.

If an event affected security or personal data, involve the appropriate legal, privacy, and security owners instead of treating the status template as complete guidance. Notification duties and timelines vary. The prepared communication process should accelerate accurate coordination, not encourage the team to publish details that compromise an investigation.

Prepare for vendor incidents as well as failures in code the team owns. Hosting, payment, email, DNS, and CRM providers may publish their own updates, but the business still needs to explain the customer-facing effect. Keep contract references and escalation contacts with the runbook. Do not copy a vendor’s resolved status until the team has confirmed its own service recovered.

Photo by Markus Winkler on Pexels.