What do you say to someone after an incident?

Thank the specific thing they did, and separate the fix from everything around it. The person who kept support informed and the person who wrote the postmortem did real work that a message about “the fix” leaves out entirely.

Should you thank someone who caused the incident?

Thank them for how they handled it, yes. Teams where a mistake is followed by blame report problems later and less honestly, which makes the next incident longer. Recognising fast, honest disclosure is how you get more of it.

When should the message go out?

The following day. A thank-you posted at 3am is read by nobody and signals that everyone is still online. Wait until the people involved have slept.

Is a postmortem worth recognising on its own?

Yes. Writing an honest one is uncomfortable and time-consuming, it happens after the urgency has gone, and it is the artefact that stops the same incident twice. Almost nobody gets thanked for it.

What about the people who were not on call?

Incidents pull in support, comms and often sales. The engineer gets the credit and the person who spent four hours on the phone to customers usually gets none, despite having the worse afternoon.

Recognition messages

Thanking Someone After an Incident: 10 Messages

An incident ends and everyone moves on within a day. The people who spent the night on it rarely hear anything about it again.

The thank-you arrives before the hard part is done

An outage ends and the relief is immediate. The work is not. Somebody still has to write the postmortem, fix the thing that made debugging slow, and tell the customers what happened.

Recognition sent at the moment of resolution captures none of that. A message the next afternoon, naming the write-up and the follow-up fix, lands on work that would otherwise pass unmentioned.

Thank the disclosure, not just the fix

If somebody’s change caused the incident and they said so within a minute, that is the behaviour to recognise. The alternative, where people go quiet and hope, is how a twenty-minute incident becomes a three-hour one.

10 messages you can send

Thank you for last night. You had the cause in twenty minutes and the fix out in forty, and then you wrote it up properly at 3am when nobody would have blamed you for going to bed.
Manager, to the responder
Thanks the tired part at the end, which is the part usually skipped.
Ravi ran that incident calmly enough that the rest of us stayed calm. That is most of what incident command is.
Peer, on composure
Names a skill people rarely put a word to.
Thank you for the status updates. Support had something to tell customers every fifteen minutes and nobody had to guess.
Peer, cross-team
Credits communication, which is invisible when it works.
You said “I don’t know yet, here is what we are checking” instead of guessing. That kept everyone useful.
Manager, on honesty
Quotes the behaviour so it can be copied.
Thanks for the write-up. It reads like an explanation rather than a defence, and that is why people will actually use it.
Peer, on the postmortem
Praises tone in a document, which is unusual and specific.
Sofia noticed the alert nobody was looking at and escalated before customers did. That is the whole ballgame.
Manager, on early detection
Recognises catching something before it became visible.
Thank you for going home at 2am when I told you to. Handing it over properly is harder than staying.
Manager, on handover
Thanks a decision most people would treat as giving up.
You spent the day after the incident fixing the thing that made it hard to debug. Nobody asked. The next one will be shorter because of it.
Peer, on follow-up
Points at unglamorous work that pays off later.
Thanks for pushing back when I wanted to roll forward. Rolling back was right and I was tired and wrong.
Manager, conceding
The sender takes the loss, which makes it credible.
Marek took the customer calls during the outage so the engineers never had to context switch. Two jobs, one of them thankless.
Manager, on shielding
Names work whose purpose was to protect other people’s focus.

What makes one land

Send it the next day, not in the channel at 3am. People are too tired to read it and it looks like you are still working.
Thank the write-up separately from the fix. They are different pieces of work and the second one is easier to skip.
Recognise the people who were not fixing it: the person handling customers, the one keeping the status page current.
Do not turn it into a lesson. An incident thank-you that becomes process feedback stops being a thank-you.
If somebody made a mistake that caused it, thank them for how they handled it. Blame produces slower disclosure next time, not fewer incidents.

Questions people ask

What do you say to someone after an incident?: Thank the specific thing they did, and separate the fix from everything around it. The person who kept support informed and the person who wrote the postmortem did real work that a message about “the fix” leaves out entirely.
Should you thank someone who caused the incident?: Thank them for how they handled it, yes. Teams where a mistake is followed by blame report problems later and less honestly, which makes the next incident longer. Recognising fast, honest disclosure is how you get more of it.
When should the message go out?: The following day. A thank-you posted at 3am is read by nobody and signals that everyone is still online. Wait until the people involved have slept.
Is a postmortem worth recognising on its own?: Yes. Writing an honest one is uncomfortable and time-consuming, it happens after the urgency has gone, and it is the artefact that stops the same incident twice. Almost nobody gets thanked for it.
What about the people who were not on call?: Incidents pull in support, comms and often sales. The engineer gets the credit and the person who spent four hours on the phone to customers usually gets none, despite having the worse afternoon.