> If the payment service went down because a config value was wrong, the incident report should say: the payment service went down because config value X was set to Y when it needed to be set to Z.

The number of junior engineers I have had to coach out of this way of thinking to get the smallest fragment of value out of a postmortem process... dear Lord. I wonder if this person is similarly new to professional collaboration.

The larger personal site is very aesthetically cool, though – make sure you click around if you haven't!

What's the mistake here? Shouldn't an incident report start with this and then continue with an analysis of the process, without too much "internal perspective"?

In my mind, the internal perspective might be useful to jot down when doing the analysis, but is too noisy to be useful to disseminate.

Yeah, I wonder if the author has been in a situation where a brief explanation was taken by a higher up (or a cc'd higher-up x2, or x3) as "It was entirely my fault and I'm withholding details that would further implicate me and giving only the facts that don't."

I've had to work to balance emails like this between "they don't want the nitty gritty, they just want to be satisfied the issue is solved" and "They will definitely want the nitty gritty and think something is up if the details seems suspiciously sparse". Especially if the recipients are technical, and they know that you know that they're technical. what are you hiding, Qaadika? you're usually more verbose than this.