Your Outage Is Fixed. Your Incident Report Decides Whether Customers Stay.

The outage lasted three hours. Your engineers found the cause, rolled out a fix, and watched the graphs return to normal. Then someone in the incident channel asked the question nobody had planned for: "What do we tell customers?"

What happens next is predictable. A tired engineer writes a few paragraphs at midnight. Someone in marketing softens them. Legal removes anything that sounds like an admission. By the time it goes out, the report says that "some users may have experienced degraded performance due to an issue with a third-party provider," and that "we take reliability seriously."

Your customers' engineers read that and conclude one of two things: you don't know what happened, or you won't say. Either way, the account manager now has a harder renewal conversation, and the enterprise prospect who was evaluating you during the outage has a new item on their risk list.

The outage was an engineering problem. The public incident report is a writing problem, and it is the part customers remember.

An incident report is not a postmortem with the names removed

Most engineering teams already know how to write an internal postmortem. Google's Site Reliability Engineering book describes the blameless version many teams follow: a written record of the incident, its impact, the actions taken, the contributing causes, and the follow-up work, focused on causes rather than on who to blame. That document is written for your own engineers, so they can learn from it.

A public report has a different reader and a different job. The reader is a customer, often a technical one, who needs to decide whether to keep trusting you. The job is to answer the questions they're already asking:

1. What broke, and who was affected? In concrete terms, with times and time zones.
2. Why did it happen? At a level of detail a competent engineer can evaluate.
3. Why didn't your safeguards catch it? This is the question they care about most, and the one most reports skip.
4. What are you changing? Specific commitments, not intentions.

Trimming an internal postmortem doesn't produce that. You end up with either too much internal context or so little that the report says nothing.

How incident reports lose trust

The same patterns show up again and again:

• The passive voice. "An issue was identified" and "a configuration change was made" read as evasion, even when nobody meant to evade anything. "We deployed a configuration change that…" is shorter and more credible.
• Blaming a vendor without owning the dependency. Your provider may have failed, but your customers bought your product. If one vendor failing took you down, that is your architecture, and the report should say what you're doing about it.
• "Out of an abundance of caution." Customers read this as filler. Say what you did and why.
• Vague remediation. "We are improving our monitoring" commits to nothing. "We are adding an alert on queue depth that pages on-call before backlog affects API latency" tells a technical reader you understand the failure.
• Silence on detection. If customers noticed before your monitoring did, they know. Pretending otherwise costs more than admitting it.

None of these are about grammar. They're about whether the writer understood the incident well enough to explain it plainly.

Write the template before you need it

The worst time to decide how your company communicates about outages is during one. Here's what you can do this quarter, without hiring anyone:

1. Agree on a structure now. Summary, impact (with start and end times), timeline, root cause, why detection and safeguards didn't stop it, and what you're changing, with owners and target dates where you can share them.
2. Decide who signs it. A report signed by a named engineering leader reads very differently from one signed "The Team." Pick that person in advance.
3. Pre-clear the language with legal. Sit down with counsel once, in a calm week, and agree on what you can say about causes and commitments. Then the review during an incident is a quick check, not a negotiation from scratch.
4. Set a publishing target. A short status update should go out quickly. The full report can follow within days, once the causes are understood. Commit to a timeline and say it in the first update.
5. Rewrite an old one. Take your last customer-facing incident notice and rewrite it against the four questions above. Comparing the two versions is the fastest way to show your leadership team why this matters.

Why this is a ghostwriting job

The person who understands the incident is the engineer who was on call. The person whose name should be on the report is usually a CTO or VP of Engineering. Neither of them has a free day in the week after a major outage, because they're doing the remediation work the report promises.

That is the gap a technical ghostwriter fills. The process is the same interview-driven approach I described in Your Engineering Blog Didn't Run Out of Ideas — It Ran Out of Writers: start from the artifacts (the incident channel, the timeline, the internal postmortem), interview the engineers who handled it, and write in the voice of the leader who will sign it. The engineers spend an hour talking and a short time checking the draft for accuracy. The executive reviews a report that already sounds like them.

That only works if the writer can follow the technical story. Someone who doesn't understand why a retry storm made a partial failure worse won't ask the follow-up question that turns a vague report into a credible one. I spent decades writing software before I became a technical writer, so I read an incident timeline the way your customers' engineers will. I know which details their architects will look for, and which ones only matter inside your building.

Before the next one

Every system fails eventually. What customers judge you on is how clearly and honestly you explain it afterward.

If your last incident report went out late, vague, or rewritten into nothing, I'd be glad to help you build a template and process you can use under pressure, or to write the next report with your team when you need it. You can reach me through the contact page.