The First Rule of Incident Communication

At 2:14 on a Tuesday afternoon, our payment authorization service started rejecting one in every three card transactions. I know the exact time because the first thing I did, before I understood anything, was post a message in the incident channel: "Auth failures spiking, looking now." Six words. That message mattered more than the fix that came forty minutes later.

The first rule of incident communication is simple, and almost nobody follows it under pressure: tell people something before you know everything. Silence during an incident is not neutral. It is a decision, and it is almost always the wrong one.

Silence Tells Its Own Story

When you go quiet during an outage, you are not buying yourself time to look competent. You are handing your customers, your support team, and your executives a blank page, and they will fill it in with the worst version of events. A merchant whose checkout is failing does not think "the engineers are surely on it." They think "these people took my money and disappeared." Support tickets pile up. Someone escalates to your CEO. By the time you surface with a clean, confident update, you are already answering for the twenty minutes you spent looking calm.

I have watched this play out from both sides. Early in my career I sat on a bridge call where the incident lead refused to send any external update until we had root cause. His reasoning sounded responsible: don't speculate, don't cause panic, don't commit to something we might have to walk back. What actually happened was that our largest partner's operations team, hearing nothing, assumed a security breach and started pulling their integration. We spent the next week rebuilding a relationship that a two-line status update would have preserved.

Your First Message Buys Trust You Can Spend Later

The earliest update in an incident is worth more than any that follows, and it is the one people are most afraid to send. They think it has to be accurate, complete, and reassuring. It has to be none of those things. It has to be honest and fast.

Here is what a good first message actually contains. Not much:

• What you are seeing, in plain terms ("some customers are seeing failed logins").
• That you know about it and someone is actively working it.
• When the next update will come, even if the answer is "in 15 minutes, whether or not we know more."

That last point is the one people skip, and it is the load-bearing one. Committing to a next update time does two things. It stops everyone from pinging you every ninety seconds, because they know when to check back. And it forces you to keep talking, because you have made a promise on the record. I have learned to distrust my own instinct to say "we'll update when we have news." News-driven updates die the moment the incident gets hard, which is exactly when people most need to hear from you.

One Incident, Three Different Conversations

The mistake I see most often from smart engineers is treating incident communication as a single broadcast. It isn't. You are running at least three conversations at once, and they need different content, different cadence, and different vocabulary.

The internal technical channel is where the actual debugging lives: raw logs, hypotheses, half-formed guesses, the freedom to be wrong out loud. The stakeholder channel, where your VPs and support leads sit, needs impact and timelines, not stack traces. The external status page needs the least technical detail and the most emotional discipline. When you blur these, you get disasters like an engineer's "I think the database is corrupted, we might lose data" leaking straight onto a public status page. That sentence was fine in the debug channel. On a status page it is a run on the bank.

Keep a human being between the debug channel and everything else. On my teams that person is the incident commander, and one of their few real jobs is translation. They pull signal out of the technical chaos and shape it for people who cannot read a Grafana dashboard and should not have to.

Name What You Don't Know

There is a particular kind of honesty that reads as more trustworthy than confidence, and it is admitting the boundaries of what you know. "We have confirmed that card payments are affected. We have not yet confirmed whether bank transfers are impacted, and we're checking now." That second sentence is worth more than a paragraph of reassurance.

People in a crisis are trying to make their own decisions. A merchant needs to know whether to put up a "we're having issues" banner. A partner's on-call needs to know whether to fail over to a backup provider. Tell them precisely what is confirmed and what is still open, and you let them act instead of guess. Paper over the unknowns with soothing language, and you take that ability away — then you get caught out when the thing you glossed over turns out to be the real problem.

The instinct to protect people from uncertainty is really an instinct to protect yourself from looking uncertain. Those are not the same thing, and your customers can tell the difference.

Cadence Beats Cleverness

A steady drumbeat of thin updates beats one brilliant update an hour later. I would rather send five messages that each say "still working, no change, next update in 15 minutes" than go dark while I craft the perfect explanation. The rhythm itself is the message. It says: we are here, we have not forgotten you, the lights are on.

During a payment processor outage that hit us for close to three hours, we posted updates every fifteen minutes on the dot, even when the update was genuinely nothing. Afterward, one of our larger merchants told me the constant heartbeat was the reason they didn't switch providers that day. They said, and I remember this clearly, that they had been through outages with vendors who vanished for an hour, and the difference wasn't the downtime, it was whether anyone was talking to them while it happened. The fix was out of our hands, upstream at the processor. The communication was entirely in our hands, and it was the only thing that day I felt good about.

Cut the Weasel Words

Corporate incident language is a genre of its own, and it is poison. "We are experiencing intermittent degradation of service availability" means "some of your stuff is broken," and everyone knows it, which is exactly why the padded version breeds contempt. The gap between how bad it obviously is and how mild you're pretending it is becomes its own credibility problem.

Write the way you would talk to a colleague you respect. "Payments are failing for about a third of transactions. We know why now and we're deploying a fix. Next update in ten minutes." Plain, specific, no hedging adjectives doing PR work. The phrase "some users may be experiencing" is almost always a lie of scale. You usually know roughly how many, and rounding "a third of everyone" down to "some users" is the kind of thing an angry account manager quotes back at you in the post-incident review.

Don't Fumble the All-Clear

The end of an incident is where discipline tends to collapse. The fix goes in, the graphs recover, everyone exhales, and the final message never gets sent because the people who were watching have mentally moved on. This is a mistake. The resolution message is the one that closes the loop for everyone who saw the problem start and never heard how it ended.

Send it deliberately. Confirm the service is fully recovered, state clearly when it recovered, and give a one-line honest summary of what happened. Then promise a proper write-up and actually deliver it. I hold my teams to a rule: no incident is closed until the resolution message is posted to every channel where we posted an alarm. If you sounded the siren in five places, you owe an all-clear in five places. Leaving even one channel showing a red banner overnight erodes trust more than the outage did.

Communication Is a Muscle, Not a Document

You cannot write good incident updates for the first time during a real incident, when your heart rate is up and a director is DMing you for an ETA. The composure to type a calm, honest three-line update while everything is on fire comes from having done it before in conditions that didn't matter.

This is the entire point of game days and incident drills, and it is why I care less about whether the team fixes the injected fault quickly and more about whether someone posted a coherent status update within two minutes of it starting. We rotate the incident commander role deliberately, including onto engineers who hate the spotlight, precisely so the skill spreads. The technical fix is often the easy part; a senior engineer can usually find the bad deploy. Standing in front of frightened stakeholders and saying "here's what we know, here's what we don't, here's when I'll be back" without either panicking or lying, that takes reps.

Conclusion

Here is the thing I wish someone had told me fifteen years ago: your customers will forgive the outage. Systems fail, and anyone running real infrastructure knows it. What they will not forgive is the feeling that you left them alone in the dark, wondering whether anyone was even awake. The outage is a technical event. The silence is a character reference. Get in the habit of talking early and talking plainly, and you will find that most of the anger that surrounds an incident never had anything to do with the incident at all.