Post-Incident Architecture Review
After the outage, the harder question: what made it possible?
- Turnaround
- 5 business days
- Who it is for
- Teams who have just had a significant outage.
01 — The problem
A postmortem explains the incident. It rarely addresses the architectural decision that made that class of incident available in the first place — which is why the next one rhymes with the last.
02 — What is included
Exactly what you get, and nothing vague.
- Independent review of the incident timeline and contributing factors
- The architectural decision that made this failure class possible
- Blast-radius analysis: what else shares that failure mode right now
- Prioritised remediation separating the immediate fix from the structural one
- Detection gap review — why monitoring did not catch it sooner
03 — What this usually finds
The recurring ones, named up front.
- The same failure mode present in three other services
- A dependency nobody had documented as critical
- Rollback that was never tested under load
- Alerting that fired correctly but routed nowhere useful
Listed because they recur, not because they are guaranteed. The audit reports what is actually there.
Next step
Twenty minutes to find out whether this is worth doing.
Every engagement runs under a signed mutual NDA with a read-only IAM role. If the audit would not pay for itself, I will say so on the call.