A practical website incident-response runbook for small teams

What counts as a website incident?

Treat a website problem as an incident when it interrupts an important customer or staff journey, exposes information, damages data integrity, or creates material business risk. A total outage is obvious, but a working homepage can hide a failed checkout, rejected lead form, broken login, missing inventory update, or analytics outage. The runbook should therefore begin with business journeys and dependencies, not only server uptime.

Write down the command path before anything breaks

Even a two-person team needs one named incident owner. That person keeps the shared picture current, assigns work, protects the recovery plan from conflicting changes, and decides when to escalate. The person investigating should be able to focus on evidence and restoration while a separate owner handles stakeholder updates when the situation is large enough.

• Name a primary and backup incident owner.
• Keep hosting, DNS, repository, monitoring, payment, email, and vendor access ownership current.
• Choose one incident channel and one live incident document.
• Store the runbook somewhere that remains available when the website or its main workspace is unavailable.

Triage impact before diagnosing the cause

Start with what users cannot complete, when the failure began, which environments and regions are affected, and whether data or security may be involved. Confirm the symptom from outside the administrative session. Record status codes, timestamps, screenshots, recent releases, vendor status, and representative failed requests. Do not begin with a preferred theory; an expired domain, configuration change, application regression, third-party outage, and compromised credential can present similar symptoms.

Stabilize the customer journey

The first objective is safe restoration, not a perfect explanation. Pause deployments and scheduled changes, preserve relevant evidence, and choose the smallest reversible action that reduces impact. That may mean rolling back a release, disabling one integration, restoring a known-good configuration, switching to a documented manual process, or showing an accurate temporary notice. Avoid multiple people changing production independently because overlapping fixes make both recovery and diagnosis harder.

Communicate facts on a fixed rhythm

An incident update should state the observed impact, when it started, what the team is doing, any safe workaround, and the time of the next update. Separate confirmed facts from hypotheses. Avoid promising a recovery time before the team has evidence. Internal updates can include more diagnostic detail, while customer-facing messages should remain plain, accurate, and proportionate to the real impact.

Use explicit recovery checks

A green deployment or a successful homepage request does not close an incident. Test the exact failed journey with representative valid, invalid, empty, boundary, and duplicate inputs where relevant. Check downstream records, notifications, payment or inventory state, logs, queues, analytics, mobile behavior, and accessibility of the recovery path. Confirm that temporary controls did not weaken authentication, privacy, indexing rules, or data validation.

Close with evidence, ownership, and cleanup

Record the recovery time, deployed version or configuration, customer impact, affected records, and any manual reconciliation still required. Remove temporary access and bypasses, re-enable paused jobs deliberately, and assign each follow-up action to an owner with a due date. A post-incident review should explain contributing conditions and system gaps without turning into a search for one person to blame.

Practice the runbook before relying on it

A short tabletop exercise exposes missing access, unclear ownership, stale contacts, untested backups, and recovery steps that exist only in someone’s memory. Choose a realistic scenario, walk through detection to closure, and update the runbook immediately. Incident readiness is an operating capability: it improves through routine use, review, and evidence-backed changes.