Incident work is some of the hardest work to get credit for in a promotion case, and on-call engineers usually find that out the first time they sit down to write their own. You remember the 2 a.m. database failover, the rollback you called while everyone else was still reading logs, the alert you rewrote so nobody got paged for it again. Then you open the self-review template and none of it seems to fit the boxes.
This one is for anyone heading into a review cycle with a year of pager duty behind them and not much on paper to show for it.
Why Incident Work Disappears by Review Time
There are a few reasons, and none of them are about whether the work mattered.
The first is plain memory. An incident is intense for three hours and then it's over, and by the time promotion season comes round, months later, the details have gone soft for everyone, including you. Julia Evans made this point years ago in her essay on writing a brag document: "if you don't remember everything important you did, your manager (no matter how great they are!) probably doesn't either."
The second is that good incident response looks like nothing happened. A well-handled outage is shorter and quieter than a badly handled one, and "it was only 20 minutes" doesn't sound like an achievement to someone who wasn't on the call.
The third is the format. Promo committees mostly read documents written about people they didn't work alongside. They can't weigh what never reached the page.
A Count Isn't Evidence
The most common incident line in a self-review is some version of "Primary on-call for Q2, resolved 30+ incidents." It's true, and it tells the reader almost nothing. It says you were available. It doesn't say what you decided, what changed because of you, or whether the next person on rotation had an easier week.
A MentorCruise career guide for SREs names the early-career version of this: junior engineers "accumulating knowledge without accumulating evidence." The same piece describes the mid-level plateau as "excellent reactive work with no proactive track record." A pager count walks you straight into that. You get very good at responding, which is valuable, and the document you hand in describes nothing beyond responding.
Three Kinds of Incident Story That Hold Up
Not every incident is worth a paragraph. The ones that are tend to fall into three groups.
A decision you made under uncertainty. You called the rollback before root cause was known, or argued against a restart that would have wiped the evidence, or escalated to a team who didn't think it was their problem. At senior level a committee is largely asking whether you exercise judgment when the information is incomplete, and an incident is one of the few places that judgment gets recorded with timestamps.
A fix that removed a class of incident, not one instance. This is where the proactive track record comes from. If a postmortem action item you owned stopped a whole category of page from firing again, it belongs in the case, with before-and-after numbers if you have them. It's also why I keep arguing that postmortems need action items with owners and deadlines. An action item that never ships is a promo story that never exists.
A change to how the team responds. You wrote the runbook other people now reach for, fixed the alert routing, took the incident commander role so others could stay on the fix, or wrote the shift notes that stopped the next person from treating three unrelated pages in one night as one incident. Tanya Reilly calls this kind of thing glue work. It makes other people faster, and it's very easy to leave out because it doesn't feel like "your" work.
Rewriting One Line
A hypothetical, to make it concrete. Say the original line reads:
Handled the checkout latency incident in March.
A version a committee can use:
During the March checkout latency incident, spotted connection-pool exhaustion while the team was still investigating the database, and called a rollback of the previous day's config change 25 minutes in, before root cause was confirmed. Owned the follow-up: a pool-saturation alert and a pre-deploy check on pool size changes. No repeat in the six months since, and the check has blocked two bad configs.
It's longer, but every clause is something the reviewer can check or weigh: a decision, when you made it, what you did afterwards, and whether it lasted. Link the postmortem so they can read the details themselves.
Write It the Week It Happens
That rewrite is easy the week after the incident and close to impossible in November. Keep a running file (a doc, a note, whatever you'll actually open) and spend ten minutes on it after each incident you worked: what you decided and when, what you owned afterwards, and a link to the postmortem. When a follow-up lands, go back and add the result.
The same notes pay off outside promotion season. "Tell me about an incident you handled" is close to guaranteed in an interview, which I covered in what SRE interviews are actually testing for, and the stories that work there are the same three kinds as above.
What to Leave Out
Heroics, mostly. "Worked 14 hours straight to restore service" reads as dedication to you and, to a lot of senior reviewers, as a sign that something about the system or the rotation is broken. If you did pull a long night, the more useful story is usually what you changed so nobody has to do it again.
Blame, too, even softened. "Recovered from another team's bad deploy" makes the reader wonder how you'll behave in the next cross-team incident. Describe what you did, not what they did.
And volume. Three incidents written up properly will do more for your case than thirty listed.
None of this replaces a manager who actually advocates for you. It gives them something to advocate with.