Incident response
Purpose: Run AEM incidents with clear severity, roles and the platform-specific first moves that shorten them.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Everyone gets a turn |
| Tech leads | Incident commanders |
Severity anchored to user impact
| Sev | Definition (site terms) | Response |
|---|---|---|
| 1 | Site down / purchase-lead flows broken / data exposure | Page now; incident commander; business comms |
| 2 | Major feature broken, workaround poor (plan pages render without premiums) | Page in hours; commander |
| 3 | Degraded, workaround exists (authoring slow, one component broken) | Business hours |
| 4 | Cosmetic/minor | Backlog |
Roles from sev2 up: commander (decisions, comms cadence), operator(s) (hands on keyboards), scribe (timeline — the post-incident review is only as good as the timeline). The commander does not type.
AEM-specific first moves (after the triage method)
| Symptom | First move |
|---|---|
| Site down | Which layer? CDN status → dispatcher direct → publish direct — binary-search the chain |
| Everything slow post-deploy | The lever question: rollback decision in 5 minutes, not 50 |
| Content not updating | Replication queues + .stat files (replication blocked) |
| One publisher weird | Pull it from LB first, diagnose second — traffic tolerance exists for this |
| Author down | Publish keeps serving (say so in comms — "the website is fine"); cold standby decision per RTO |
| Suspected security event | Stop, engage security response — different playbook, preserve evidence, no cowboy fixes (incident type) |
Stabilise > diagnose
Mid-incident, prefer the reversible stabilising action (LB removal, cache serve-stale, feature flag off, rollback) over the clever root-cause fix. Root cause is for the calm afterwards — captured in a blameless review whose actions actually land in the backlog. An incident without a review is a rehearsal for its sequel.