👋 Hey {{first_name|there}},
This is the last one in the arc. We’ve spent five weeks on four incidents, and every one of them started inside the company it happened to. There was no provider, no supplier, and nobody else to point at.
Today I want to get the five checks onto one page you can actually use. I also want to explain why, from next March, the links between small failures start to matter nearly as much as any single big one, at least if you’re regulated in the UK.
It’s a shorter one. If you’ve been reading along, you’ve done the heavy lifting already.
Why this matters
On the surface, these incidents don’t have much in common. One was a bank showing customers each other’s transactions; another an exchange whose gateway fell over. Then there was a bot-scoring file that doubled in size, a WAF testing tool switched off in a hurry, and a rollback that couldn’t reach its own tools.
Look underneath, and the same handful of things keep turning up. A change landed somewhere shared. Production read something nobody had deployed. A quick route skipped checks the slow route would have run. And twice, noticing the problem or getting back from it depended on the thing that had just broken.
Most incident reviews miss this because they take one incident at a time. Each postmortem gets its own timeline and its own actions, gets closed and goes in a folder. When the next incident with the same shape comes along, it gets a fresh folder.
From 18 March 2027, that gets harder to keep doing in the UK. Under the FCA and PRA’s new reporting rules (PS26/2 and PS7/26), an operational incident can be a single event or a series of linked events. Linked means events whose combined effect disrupts the firm, or several events coming from the same root cause. Whether a given series has to be reported still depends on its impact. Either way, you’ll need to be able to see a series as a series. Most incident tooling I’ve used only really sees one ticket at a time.
I’d want to do this even without the regulator, to be honest. When the same pattern keeps showing up, it’s telling you where the structural fix needs to go.
🧭 The shift
From: “Every incident gets its own postmortem.”
To: “Every incident gets its own postmortem, and somebody checks which earlier ones share its root cause.”
🔍 The lens: three questions and a tally
The five checks from this arc boil down to three questions to ask before a change goes out. Then there’s one exercise to run on the changes that have already gone wrong.
Where does it land, and what else lives there? That’s the reach check from #74, plus the shared-state part of the ownership check from #73. Look at the cluster, gateway, cache, or connection pool the change actually touches, and at whatever else leans on it. Which service the change was written for matters a lot less.
What’s changing that isn’t in the deploy log? This covers the generated files and feeds production reads without anyone deploying them (#75). It also covers the little supporting changes that slip out the quick way next to an emergency fix (#76). If the change history for an incident hour has one entry in it, I’d assume something’s missing.
How would you know it’s wrong, and how would you get back? You want a check that asks whose data came back, as well as whether anything came back at all (#73). You also want a rollback that doesn’t run through the thing being changed, and a break-glass route that someone has actually timed for when it does (#77).