Monitoring
Status Pages
Pricing
In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint.
This post assumes that context.
The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already going wrong?
One answer, used quietly but consistently by high-performing teams, is the checklist.
Given that engineers operate under pressure, uncertainty, and incomplete information during incidents, checklists serve a very specific role.
They are decision support, not documentation.
A good checklist:
A bad checklist:
The difference isn’t intent. It’s design.
In reliability-focused teams, operational tools like checklists are treated as aids to decision-making under uncertainty. They’re not there to be used as exhaustive instructions.
Not all checklists reduce cognitive load. Some quietly increase it. In practice, the usefulness of a checklist comes down to a few constraints.
If a checklist has more than roughly 15–20 items for a single phase, it’s probably doing too much. Under pressure, long lists increase scanning time and encourage skipping. Breaking prompts into short, situational sections keeps them usable.
Organising prompts by moment, e.g. the first few minutes, active mitigation, standing down etc, mirrors how incidents actually unfold. Engineers shouldn’t have to translate process into reality while things are breaking.
Effective checklists use plain language and avoid internal jargon or shorthand. Prompts should be understandable even by someone who didn’t build the system. Questions tend to work better than commands because they encourage thinking rather than rote execution.
A checklist that never changes is a warning sign. The most useful ones evolve in response to real incidents, near-misses, and moments of hesitation.
The goal isn’t perfect coverage. It’s to provide clarity when clarity is hardest to come by.
What follows is one example of how teams reduce cognitive load during incidents. It’s not a universal template; rather a starting point to adapt to your own systems and failure modes.
The structure reflects how incidents actually feel in practice.
Before jumping to fixes, teams need to orient themselves.
Helpful prompts include:
These prompts exist to prevent teams from solving the wrong problem first.
Once oriented, the focus shifts to limiting damage. Useful prompts here include:
This phase is about resisting the urge to “do more” when clarity is lacking.
Many incidents last longer than they need to because teams aren’t sure when it’s safe to stop.
Before standing down, prompts like these help restore confidence:
This phase exists to avoid both premature confidence and unnecessary caution.
When internal dashboards are noisy, delayed, or contradictory, independent signals become especially valuable.
External monitoring helps answer a few simple but critical questions:
An outside-in signal provides a shared point of reference when internal views are inconclusive. That common ground helps teams align decisions and regain confidence.
This is where tools like StatusCake are most useful; not as a driver of incident response, but as a reliable confirmation when it matters most.
A good checklist is never finished. It evolves because:
In reliability engineering, this kind of iteration is expected. Operational practices improve by learning from real incidents, not by trying to predict every failure in advance. And every “we weren’t sure what to do next” is feedback about the system, not the individual.
That’s how checklists become leverage; they’re small refinements that compound across future incidents.
Checklists won’t prevent every incident. That’s not their job. What they do is:
They help teams respond with confidence rather than panic.
Checklists are not the goal. They’re a tool. They exist because modern systems are complex, change is fast, and humans operate under pressure.
If teams need checklists to work safely during incidents, the next question becomes:
What kind of systems, signals, and incentives reduce the need for those checklists in the first place?
That’s where we’ll explore next. We’ll zoom out from incident response to designing systems that create confidence by default.
If you’d like to explore the ideas behind checklists, human factors, and reliability engineering in more depth, the following books are excellent starting points:
Across very different domains, these works reinforce the same idea. That systems should be designed to support humans, especially when conditions are difficult.
Share this
4 min read On 13th August 2026, a storm knocked out cooling at RadiusDC’s Phoenix data centre, which hosted essential Namecheap operations. To protect hardware from thermal damage, Namecheap took services offline while temporary chillers were brought in. The incident and recovery ran for roughly 30 hours, with Namecheap’s own site unreachable for about 11 hours 42 minutes
3 min read On Wednesday 19 August, Monzo had an outage. DownDetector logged more than 3,000 reports by midday. Monzo’s own statement was direct about what it did next: it activated Monzo Stand-in, its fully independent backup bank, while it investigated an issue affecting customers. By the end of the day, Monzo said the issue was resolved and
3 min read GitHub’s incident on 17 August 2026 ran from 13:28 to 21:15 UTC, seven hours and forty-seven minutes. At peak, web and API traffic saw error rates of around 20%, while archive and raw-content downloads reached roughly 50%. SAML and OIDC authentication, SCIM and Team Sync were affected alongside Git operations, Actions, Pages, Issues, Pull Requests
3 min read Adding a new website, launching a customer portal, or handing a service to a new team should be straightforward. Setting up monitoring is part of that job, but it is easy for a manual step to be missed when information is spread across several systems. StatusCake now integrates with viaSocket, giving teams a way to connect
7 min read A website may be standing and still be in trouble. It may answer a request, return a cheerful 200 OK, and yet load slowly enough that visitors begin to lose patience. Its certificate may be nearing expiry. Its domain records may have changed. A server may be filling its disk in the background, patient and
6 min read StatusCake tells you that something might be broken. Hermes can check whether it really looks broken, decide who should hear about it, send the email, and keep the record for tomorrow morning’s summary.
Find out everything you need to know in our new uptime monitoring whitepaper 2021
