Website Outage Incident Response Playbook for Agencies

August 8, 2026 · 8 min read

When a client website goes down, the agency should confirm the customer impact, declare an incident early, assign one coordinator, stop risky changes, choose the safest mitigation, communicate what is known, and verify the full business journey before closing. Root-cause analysis comes after service is stable.

For a small agency, the response does not need enterprise bureaucracy. It needs explicit roles, UTC timestamps, a decision log, predictable updates, and a pre-agreed authority model.

At a glance: the first 15, 30, and 60 minutes

First 15 minutes

• acknowledge and confirm the signal independently;
• identify affected websites, regions, pages, and user journeys;
• classify severity and declare an incident;
• freeze unrelated production changes;
• assign incident lead, technical lead, and communications owner;
• open the incident record and preserve evidence;
• send the first client acknowledgement when the trigger is met.

By 30 minutes

• choose mitigation: rollback, failover, feature disablement, cache/static mode, vendor escalation, or controlled recovery;
• check recent deployments and shared dependencies;
• state the next update time even if there is no estimate;
• escalate to hosting, CDN, DNS, payment, or other owners;
• identify security indicators and branch to the security process if necessary.

By 60 minutes

• restore the most important safe customer journey or document why mitigation is blocked;
• bring in additional expertise without creating an uncontrolled crowd;
• update impact, actions, and next update time;
• prepare continuity workarounds;
• continue evidence capture and hand over cleanly across time zones if required.

Declare an incident early

An event should become an incident when any agreed trigger is met, for example:

• customers cannot complete a critical journey;
• the failure is visible to the client or public;
• a second team or external provider is required;
• impact is spreading or not understood;
• recovery requires rollback, failover, or privileged emergency access;
• concentrated investigation has not resolved the event within the policy threshold;
• security, privacy, integrity, or fraudulent redirection is suspected.

Google SRE recommends declaring early rather than introducing structure late into a growing event.

Assign roles, even in a three-person agency

Role	Owns	Must not become
Incident lead	priorities, coordination, decisions, escalation	the main person editing production
Technical lead	diagnosis, mitigation, recovery, validation	the client spokesperson
Communications/scribe	timeline, client updates, status page, evidence	an unapproved source of technical guesses

With two people, combine communications and incident lead. With one person, use the checklist and decision log to separate the roles mentally; call for help early on a P1.

Confirm impact, not just the alert

Ask:

• Is the symptom reproducible from another network or region?
• Is the canonical URL failing, or only one path?
• Does the CDN answer while the origin or application is unhealthy?
• Can users submit forms, log in, search, check out, pay, or book?
• Is data stale, duplicated, delayed, or exposed?
• Which client, brand, geography, or customer segment is affected?
• Did a deployment, DNS change, certificate renewal, vendor incident, or traffic spike occur?

Do not spend 20 minutes proving every detail before declaring. Capture the uncertainty and continue.

Stabilise before finding the perfect cause

Prefer reversible actions with understood blast radius:

1. stop the current rollout;
2. roll back the last known risky change;
3. disable a failing optional integration or feature;
4. switch to a documented degraded mode;
5. serve a safe static page or alternate contact path;
6. fail over only through a rehearsed procedure;
7. restore data only after defining the recovery point and reconciliation plan.

Avoid simultaneous untracked changes. A successful emergency fix that cannot be explained or reproduced creates the next incident.

Copyable incident record

# Website incident record

Incident ID: [ID]
Declared: [UTC timestamp]
Severity: [P1/P2/P3/P4]
Incident lead: [role/name]
Technical lead: [role/name]
Communications owner: [role/name]

## Current impact
- Affected client/service: [value]
- Affected journeys: [value]
- Regions/users: [known / unknown]
- Start time: [known / earliest evidence]
- Workaround: [value or none]

## Current hypothesis
[Clearly label facts, evidence, and hypotheses]

## Timeline
- [UTC] Signal received: [source]
- [UTC] Impact confirmed: [evidence]
- [UTC] Incident declared: [decision]
- [UTC] Action: [owner, result]

## Communications
- First client update: [UTC/link]
- Status page: [link]
- Next update due: [UTC]

## Open actions
- [ ] [action] — [owner] — [due/checkpoint]

## Recovery criteria
- [ ] Critical journey succeeds
- [ ] External monitoring is healthy from agreed regions
- [ ] Queues/integrations are reconciled
- [ ] Error/latency signals remain stable for [window]
- [ ] Client has received recovery update

Client communication rule

The first update should include confirmed impact, what the agency is doing, any safe workaround, and the next update time. It should not include an unverified cause or an optimistic restoration estimate.

Example:

We have confirmed that checkout is failing for some visitors. The storefront remains available, but affected customers cannot complete payment. Our team is working with the payment provider and testing a safe workaround. We will send the next update by 14:30 UTC, even if the status has not changed.

Use the dedicated client outage communication templates for acknowledgement, ongoing updates, recovery, and delayed-resolution messages.

Security branch

Treat the event as potentially security-related when you see unexpected administrators, defacement, injected scripts, changed payment or contact details, suspicious redirects, credential exposure, malware, unexplained data changes, or unusual privileged access.

In that branch:

• preserve logs and volatile evidence;
• restrict access and revoke compromised secrets through the security runbook;
• do not destroy evidence with broad cleanup before capture;
• notify the designated security and client decision-makers;
• follow applicable contractual, legal, cyber-insurance, and regulatory procedures;
• separate public communication from speculative attribution.

NIST SP 800-61 Rev. 3 places incident response within wider risk management, preparation, detection, response, and recovery activities. A simple availability playbook does not replace a security incident plan.

Verify recovery end to end

Do not close because the homepage is green.

Validate:

• canonical URL and critical paths from relevant regions;
• form, login, checkout, payment, booking, or other affected journey;
• downstream email, CRM, ERP, fulfilment, and queue state;
• data integrity and duplicates after retries or restore;
• error rate, latency, resource pressure, and security indicators;
• monitor recovery for a defined observation window;
• client-facing status and workaround withdrawal.

If the website works but the integration backlog is growing, the incident is mitigated, not fully resolved.

Handover across time zones

Use a written handover:

Current impact:
Current severity:
What changed during this shift:
Working hypothesis and confidence:
Actions completed and results:
Actions explicitly not attempted:
Risks and unsafe actions:
Next decision point:
Open vendor/client escalations:
Next client update due:
New incident lead accepts at [UTC]:

The outgoing lead remains responsible until the incoming lead explicitly accepts.

When to end the incident

Close the live response when:

• agreed recovery criteria are met;
• the observation window is complete;
• remaining work is safe to schedule normally;
• the client and status page are updated;
• temporary access, suppressions, and workarounds have owners and expiry;
• an incident report or postmortem requirement is assigned.

Common mistakes

• every engineer changes production independently;
• nobody owns communication;
• the team waits for a root cause before mitigating;
• updates say “we are investigating” without impact or next time;
• a vendor is blamed before evidence exists;
• a P1 relies on a single Slack channel;
• the incident is closed on a 200 OK while orders remain queued;
• evidence and timestamps are reconstructed from memory the next day.

FAQ

Who should be incident commander in a small agency?

The person best able to coordinate priorities and decisions, not necessarily the strongest debugger. On a small event the role may rotate.

Should the agency tell the client before knowing the cause?

Yes, when the agreed communication trigger is met. Communicate confirmed impact and next steps; label uncertainty.

What if the outage belongs to a hosting or SaaS provider?

The agency still owns its agreed coordination and communication duties. Escalate to the provider, preserve evidence, and consider documented workarounds.

When is a postmortem required?

Define triggers in advance: material customer impact, data loss or integrity risk, emergency access, long recovery, manual discovery, repeated incident, or stakeholder request.

Sources and further reading

• Google SRE: Managing Incidents
• NIST SP 800-61 Rev. 3
• Google SRE: Postmortem Culture

Reviewed: 8 August 2026.

Next: Incident severity levels for web agencies and client outage communication templates.

Pingvera can shorten detection and provide external evidence. The agency's playbook still decides severity, authority, mitigation, communication, and safe closure.

Read next: Client Website Monitoring Policy Template · Incident Severity Levels for Web Agencies.