The product has been down for fourteen minutes. You know it is down, you do not know why, and three people are looking at it. Messages start arriving in the inbox.
What you do in the next twenty minutes will weigh more on your relationship with those customers than how long the fix takes. And that is not a nice line: people forgive an outage fairly well, and forgive being left in the dark fairly badly.
What the customer is actually calculating
When something breaks, whoever is affected is not evaluating your engineering. They are answering three questions:
- Do they know? Because if not, they have to tell you, and that is now their job.
- When is it back? Not to demand anything, but to decide what to do meanwhile: wait, warn their team, find another route.
- Is it going to happen again? This one arrives later, and it is the one that decides renewal.
All incident communication consists of answering those three, in that order, and not wasting time on anything else.
The first twenty minutes
Say something before you know the cause
The most common mistake is waiting for the diagnosis before writing. It is understandable — nobody wants to say something that turns out to be wrong — and it is exactly backwards.
A message at ten minutes saying "we have detected that exports are failing, we are on it, we will write again in thirty minutes" answers the first two questions without committing to any cause. And it does something more important: it cuts off the trickle of messages. Every customer who sees that notice is a ticket that does not arrive, and mid-outage the team has no hands to answer them.
Say what is not working, not what failed
"We are experiencing issues with an internal service" helps nobody. "CSV exports are failing; the rest of the product is working normally" does, because it tells each customer whether they are affected.
The list of what is working is the part almost nobody writes and the one that reassures most.
Commit to the next update, not to the fix
"We will write again at 11:30" is a commitment you can keep. "It will be resolved within the hour" is one you do not control, and if you miss it you have turned a technical problem into a credibility problem.
And then write at 11:30 even with nothing new. "Still on it, we know it is the database, next update at 12:00" looks like an empty message and is not: it confirms somebody is awake.
During
One place. A status page, or a thread, or a channel. What cannot happen is the information being split between what gets said in chat, what gets posted on the company account and what the person who emailed knows. The moment two customers compare notes and the accounts differ, the problem doubles.
The same rhythm even when nothing happens. If you said every thirty minutes, every thirty minutes. Silence reads as abandonment, always.
Nobody promises timings on their own. Mid-outage, somebody on the team, entirely well-meaning, tells a big customer it will be back "in half an hour". When it is not, that customer has a broken promise and the others do not. This is prevented beforehand: the rule is that dates come from the official update and from nowhere else.
After: the post mortem
This is the part that answers the third question — whether it will happen again — and the one almost everybody skips, because once the problem is fixed it feels finished.
A post mortem that works has four things and nothing else:
What happened, in the customer's language rather than the system's. "For 1h 47m, exports failed for 30% of accounts."
Why, at an honest level of detail. It does not need a diagram; it needs to not sound like an excuse. "A change to how we store files did not account for accounts with over 50,000 records" is enough and it is true.
What you have changed so it does not repeat. Concrete. "We added a test with realistic volume before every deploy" counts; "we have strengthened our processes" counts for nothing, and everybody knows it counts for nothing.
What happens for those affected. If there is compensation, here. If there is not, say that too.
Publishing it openly is frightening the first time and it is what builds the most trust over time. A company that describes its outages in detail is saying, without saying it, that it looks at them.
The four mistakes that cost customers
1. The apology that takes the place of the information
"We deeply regret the inconvenience caused and thank you for your patience while our team works tirelessly…" Four lines and not a single fact. Whoever reads it is looking for whether they are affected and when it is back, and has to wade through a paragraph of courtesy without finding it.
A short apology at the top and the fact immediately after. The order matters.
2. The corporate voice
In an incident, the institutional register sounds like something is being covered up. "A degradation of service has occurred" describes the same thing as "we have been down for an hour", and only one of the two sounds like a person.
3. Minimising
"A small issue affecting some users" — when that small issue cost somebody their morning — is the fastest way to turn an understanding customer into an angry one. If the incident was serious, say it was serious.
4. Telling only the people who asked
This is the most common one on small teams: you reply to the eight who wrote in and never tell the four hundred who suffered it in silence. Those four hundred are left with the experience that the product fails and nobody says anything.
What can be prepared in advance
All of this is far easier when it is not improvised at eleven at night:
- A first-notice template with blanks to fill: what is failing, what is not, when you write again.
- A status page that exists before the first outage and does not depend on the infrastructure that goes down.
- Who writes. One person, decided in advance. Two drafting in parallel produces two versions.
- An automatic notice in the inbox for the duration. It is the difference between handling eighty messages and fifteen, and the eighty arrive exactly when fewest people are free to read them.
That last point is where an AI agent does something genuinely useful in an incident, and it is not answering: it is recognising that the incoming question is about the outage, giving the current status, and not pretending to resolve it. A system that replies with a generic help article mid-incident makes things worse, because it sounds like nobody has noticed.
What is left afterwards
Almost no customer leaves over an outage. They leave over the combination of an outage and the sense that nobody was on the other side — and that does not depend on infrastructure, it depends on who writes and when.
What gets remembered six months later is not that you were down for two hours. It is whether you knew before they did.
