Faultory

Method · 5 min read

Reading a post-incident review and what it leaves out

A company's own post-incident review can be accurate and still incomplete. Learn to check who wrote it, when, in which time zone, and what it cannot show.

Backdrop: AWS servers in Ashburn, Virginia, photographed in 2020, five years before the October 2025 outage. Vahurzpu · CC BY-SA 4.0 · Wikimedia Commons.

After reading, you will be able to say who wrote a post-incident review, what it was for, and which of its claims rest on records the reader cannot see. You will also be able to separate a trigger from the conditions that let it do damage, and cross-check the document against an independent account.

01Who wrote it, and for what purpose

A post-incident review is usually written by the party that operated the system. Amazon's post-event summary of the October 2025 DynamoDB disruption describes the company's own DNS automation. CrowdStrike published a preliminary Post Incident Review, dated 24 July 2024 and updated on 25 July, and its root cause analysis followed on 6 August. Each document has a purpose, and that purpose shapes its emphasis.

Interpretation: a company's review is a primary source for what the company knew and did. It is weaker evidence on how well its own controls worked, because that is the question its author is most directly responsible for answering. Read claims about controls with that in mind, and look for the same claims in an independent account.

02Trigger and conditions

A trigger is the event that starts a failure. Conditions are the states that were already present and let the trigger do damage. In the CrowdStrike case the trigger was a Template Instance with a non-wildcard match on the 21st input. The conditions included a validator that checked against 21 inputs while the integration code supplied 20, tests that used wildcard matches, and a deployment that reached in-scope online hosts within a short window.

In the DynamoDB case the sequence starts when a delayed Enactor writes an older plan over a newer one. The conditions included a freshness check that ran once before application, and a clean-up step that could delete the plan that had become active. A review that names only the last write is accurate about the trigger and silent about the conditions. Check whether each stated cause is a trigger or a condition, and whether the document names both.

03Times, time zones and sequence

Timestamps are often the first thing to check. CrowdStrike's timestamps are in UTC and place the update on 19 July 2024. A Microsoft post dates the same event to 18 July without giving a time zone, and 04:09 UTC was still the evening of 18 July in the Americas. Both dates can describe one event, but they look different until the time zone is stated, so convert every timestamp to one zone before comparing accounts.

The DynamoDB summary gives its times in Pacific time, from 11:48 PM PDT on 19 October 2025 to 2:20 PM PDT on 20 October. The Verge report gives the AWS status dashboard's first report of issues in US-EAST-1 as 3:11 AM ET on Monday, and says some platforms were back online about four hours after Amazon's first report. Write the sequence in one zone, and mark which times come from the company and which come from a news report.

04What the document cannot show

Many reviews do not release raw logs or code. The DynamoDB sequence is reconstructed from a written summary, so the timing of the two Enactors is an inference. The summary also does not state how many customers were affected or how many requests failed in total, so the scale of the impact is not measured.

The CrowdStrike analysis includes a crash dump excerpt, but it does not count affected hosts. Microsoft's figure of 8.5 million devices was published without a stated method, and CrowdStrike's analysis reports a different measure: about 99 percent of Windows sensors were online by 29 July 2024. Scale and recovery are different measures, and neither is a crash count.

Interpretation: when a document gives a number, ask what it counts, over what period, and by which method. If the answer is not in the document, treat the number as an estimate and look for a second source before repeating it.

05An independent investigation

The National Transportation Safety Board's final report on Alaska Airlines flight 1282 offers a contrast. It was adopted on 24 June 2025 and reconstructs events at Boeing's Renton factory from production tracking records, rework records, barge logs, emails, text messages and interviews. The four bolts that secured the left mid exit door plug were missing before the airplane was delivered on 31 October 2023.

The NTSB's probable cause is Boeing's failure to provide adequate training, guidance and oversight for its parts removal process, with the FAA's oversight as a contributing factor. It could not identify the individuals who opened and closed the plug, and it does not attribute the events to any individual's misconduct. Its judgments about organizational causes rest on the records and on its interviews, which gives a reader something to test.

Interpretation: the difference lies in what the reader can check. The NTSB states that no removal record was generated and that no quality assurance inspection of the closure was performed, and a reader can set those statements against the procedure they concern. Its account of the procedure's history says it had a documented history of compliance issues for at least 10 years before the accident.

06A settled order is a bounded record

The SEC's administrative order on Knight Capital is a regulator's finding, not a company review. It documents 97 automated emails and inadequate controls over outgoing orders, aggregate exposure and incident response, and it announced a $12 million penalty on 16 October 2013. Knight settled without admitting or denying the findings, apart from jurisdiction.

Interpretation: a settled order gives the regulator's findings, not a full log of everything a company might have contested. Treat it as a bounded record. This case uses it as the evidence base for a deployment sequence, and a sound reading still asks which independent check could have stopped that sequence before its effects accumulated.

07A reading routine

Read the document in order. Note who wrote it, when, and whether the time zone is stated. Mark each claim as a trigger, a condition, a measurement, an estimate or a recommendation. Then find the independent account, if there is one, and check whether it agrees on the sequence, the scale and the cause.

Note the revisions as well. CrowdStrike's preliminary review was updated on 25 July 2024, and the root cause analysis that followed on 6 August reports a different measure of scale. A preliminary document can be accurate about one part and superseded in another, so compare the versions before quoting either.

Terms in this note

Post-incident review
A document, usually written by the organization that operated a system, that describes what happened, why, and what will change. Its author and purpose shape its emphasis. Glossary
Trigger
The event that starts a failure sequence. It is distinct from the conditions that were already present and allowed the trigger to cause harm. Glossary
Independent investigation
An investigation by a body that did not operate the system. It reconstructs events from records, testimony and physical evidence, and it can be checked against the company's own account. Glossary

Test the idea

The case files behind this note

The open record

Sources & further reading

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6

Written for Faultory by Yunus Emre Vurgun, with AI-assisted research and drafting. Editorial standards · Report an issue.