Build Your Own One-Page Production Risk Register

List each meaningful piece of your architecture as its own row: your primary database, each critical third-party API you depend on, your deployment pipeline, your background job system, and anything else that would cause real damage if it failed. Keep this granular enough to be useful but not so granular that the register itself becomes a maintenance burden nobody keeps updated. A dozen to two dozen rows is usually the right range for a small or mid-sized system.

For each row, write the specific, concrete way that component tends to fail, based on what's actually happened before, not a generic worry. 'The database connection pool can exhaust under a traffic spike' is useful. 'Database issues' is not, because it gives a new engineer nothing to actually check when something goes wrong at two in the morning. Pull this straight from past incident reviews where you have them, since the most realistic failure modes are almost always the ones that already happened once, not the hypothetical ones someone imagines from scratch.

Write down what's actually in place today to catch or prevent that failure, and be honest about gaps rather than writing down what you intend to build eventually. 'No monitoring on this yet' is a genuinely useful entry, since it tells the next person exactly where the real exposure sits, while a vague or aspirational entry just hides the gap behind a false sense of coverage. This column is the one most tempting to overstate, precisely because writing down a real gap can feel like an admission, but an honest gap is far more useful to the next engineer than a comforting fiction.

For example, a row for the primary database might read: failure mode, connection pool exhausts under a traffic spike; mitigation, an alert exists but nobody has tested the runbook it points to. That entry is more valuable than a confident line saying the database is monitored, because it tells the next engineer which step to rehearse. A useful habit is to mark each mitigation as tested, untested or absent, and to revisit the untested entries first during the quarterly review. Untested mitigations are where a comforting register most often hides a real gap, since a control that exists only on paper may not work when it's needed.

For each row, name the person or team who'd actually get paged for that failure, and the first one or two things worth checking, drawn from real past incidents where possible. This is the single most valuable column during an actual incident, since it turns a register that's merely informative into one that's directly actionable the moment something breaks at an inconvenient hour.

A register that sprawls into a lengthy document stops getting read during an actual incident, when reading speed matters most. Force yourself to keep it to one page, cutting detail rather than adding more rows, and set a recurring quarterly review where the team checks whether each row still reflects reality, since an architecture changes faster than most documentation naturally keeps up with on its own.

A one-page register comes together in these steps:

1. List each meaningful component or dependency as its own row, aiming for a dozen to two dozen rows so the register stays maintainable.
2. For each row, write the specific failure mode that has actually happened before, pulled from past incident reviews where you have them.
3. State the current mitigation honestly, including gaps such as no monitoring yet, rather than what you intend to build eventually.
4. Name who gets paged for that failure and the first one or two things to check, drawn from real past incidents.
5. Cut detail to keep it on one page, give it a named owner, and set a recurring quarterly review.

Say a quarterly review of the register surfaces a row for a background job system with a mitigation column that still reads 'manually restarted if it stops,' written eighteen months earlier when the team was smaller. In that time, the job system has taken on real, revenue-relevant work nobody explicitly decided it should carry, and the informal manual-restart mitigation quietly stopped being adequate somewhere along the way, without any single moment where that shift was obvious. The register doesn't fix the gap by itself. It's what makes the gap visible enough for someone to actually decide to fix it, rather than the team continuing to rely on tribal knowledge that hasn't kept pace with what the system actually does now.