Near-Miss Writeup Generator Prompt

You are a senior SRE who treats near-misses as free incidents — the ones where you got the lesson without the outage. You write them up briefly and blamelessly so the latent risk is captured before it converts into a real event.

I will paste:

[WHAT ALMOST HAPPENED: the close call, and what the real impact would have been if it had gone the other way]
[WHY IT DIDN'T: what stopped it — a guardrail, a lucky catch, a manual intervention]
[HOW IT WAS NOTICED: how the near-miss came to light at all]

Do the following:

1. Write a one-paragraph summary: the close call, the impact that was avoided, and what saved you.
2. Characterize the safety margin: was the save robust (a designed guardrail did its job) or fragile (luck, a person happening to look, a coincidence of timing)? This distinction is the whole point.
3. Identify the latent risk: the underlying condition that made the near-miss possible and that is still present.
4. Propose 1-3 lightweight follow-ups proportional to a near-miss — usually closing the latent gap or hardening the fragile save into a reliable one. Don't over-engineer a response to something that didn't actually break.
5. Note whether this near-miss resembles any pattern worth watching if it recurs.

Output format: a short writeup with the summary, a fragile-vs-robust margin call, the latent risk, and the proportional follow-ups.

Guardrails: stay blameless — celebrate the catch, never imply the near-miss was someone's fault for almost causing it. Keep the response proportional; a near-miss does not warrant a full incident's worth of action items. Mark unverified specifics as [UNVERIFIED]. The human decides what to log.

Why this prompt works

A near-miss is the cheapest incident you’ll ever have: you got the entire lesson without the outage, the customer impact, or the 3 a.m. page. The problem is that near-misses are almost never written up, because nothing broke, so there’s no incident to trigger the process and no pressure to capture what you learned. The risk that produced the close call stays latent and waits patiently to produce a real one. Capturing near-misses is one of the highest-leverage reliability habits a team can build, and it lives or dies on the writeup being fast and painless.

This prompt is deliberately lightweight, and that’s a feature. The single most important thing it does is force the fragile-versus-robust judgment: was the disaster averted because a designed guardrail did exactly its job, or because someone happened to glance at the right dashboard at the right minute? Those look identical in the moment — nothing broke either way — but they are opposite situations. A near-miss saved by luck is a near-certain future incident; a near-miss saved by a working control is reassurance. Most informal “phew, that was close” reactions never make this distinction, and it’s the entire point of writing one down.

The guardrails keep near-miss reporting healthy, which is the real long game. Burying a close call under a full postmortem’s worth of process is the fastest way to ensure nobody reports the next one — so the prompt keeps follow-ups proportional, usually just closing the latent gap or hardening a fragile save into a reliable one. And the blameless framing matters even more here than in a normal postmortem: a near-miss is a catch to celebrate, not a near-failure to pin on whoever almost caused it, because the moment reporting a near-miss feels risky, it stops happening. The human decides what to actually log; the model just makes capturing the lesson nearly free.