Cause & Effect — Unit 6, Upper-intermediate English

**Incident report excerpt · Payments platform · 9 May**

Engineering has **established** that the outage **stemmed from** a misconfigured cache rule introduced during a routine deploy. The change **triggered** retry loops that **resulted in** six hours of degraded checkout. Roughly forty percent of failed transactions were **attributable to** duplicate billing attempts rather than stock issues.

Several factors **contributed to** slower recovery: incomplete runbooks, unclear escalation paths, and alert fatigue. Poor documentation alone did not **result in** the initial failure, but it **led to** longer mean time to repair. **As a result**, leadership has mandated peer review for all payment-tier changes. **In light of** repeated near-misses, compliance asked whether weak ownership **underlie** recurring incidents.

**Consequently**, we will **bring about** stricter change windows and additional game days. A mis-tagged feature flag **sparked** secondary errors in the refund service, which **had the effect of** doubling support tickets. **Owing to** backlog, some merchants experienced **a knock-on effect** on settlement visibility even after checkout recovered.

The **root cause** has been remediated; **due to** delayed communication, however, churn **may** persist for one billing cycle. Finance noted the outage **could be a factor in** Q2 guidance revisions. **In turn**, Product will **lay the groundwork for** clearer customer messaging during future degradations.

**On account of** this event, incident commanders must **have implications for** how we **precipitate** future rollbacks. **Consequently**, all payment deploys will **trigger** automated canary checks before full promotion.

**Section 6 — On the phrase "root cause"**

This report has used the term **root cause** in the singular, as the template requires. The incident commander wishes to record that this framing is misleading here, and to explain why.

The cache rule **triggered** the failure. It did not **cause** it in any useful sense, because the same rule had been deployed to two other tiers that same morning without effect. What made this tier fail was the coincidence of four conditions: the rule, an unusually high retry setting inherited from a 2023 migration, a merchant integration that treats a timeout as a signal to resubmit, and a monitoring threshold set high enough that the retry loop ran for nineteen minutes before anyone was paged.

Remove any one of those four and there is no outage. Naming the deploy as the **root cause** therefore **has the effect of** directing all remediation at the last thing that changed, which is also the thing least likely to recur in the same form.

The deeper problem is that three of the four conditions **had been present for over a year** and were **individually** unremarkable. No review would have flagged them. They became dangerous only in combination, and **combinations are precisely what our change process does not examine**.

**Consequently**, the commander recommends that the post-mortem template be amended. Rather than asking what **caused** the incident, it should ask which conditions were **necessary** for it, and which of those were present before the change. The first question produces a name. The second produces a list — and the list is what the organisation can actually act on.

This recommendation **is not** a criticism of the engineer who shipped the change, and the report should not be read as one.