The product has been down for fourteen minutes. You know it's down, you don't know why, and three people are looking into it. Messages start arriving in the inbox.
What you do in the next twenty minutes will matter more to those customers than how long the fix takes. People forgive an outage fairly easily. They don't forgive being left in the dark.
What the customer wants to know
When something breaks, the people affected aren't judging your engineering. They want answers to three questions:
- Do they know? If not, the customer has to tell you, and now that's their job.
- When will it be back? Not to demand anything, but to decide what to do in the meantime: wait, warn their team or find a workaround.
- Will it happen again? This one comes later, and it's the one that decides the renewal.
Good incident communication answers those three, in that order, and skips everything else.
The first twenty minutes
Say something before you know the cause
The most common mistake is waiting for the diagnosis before writing. Nobody wants to say something that turns out to be wrong, but waiting gets it backwards.
A message at minute ten saying "exports are failing, we're on it, next update in thirty minutes" answers the first two questions without committing to a cause. It also stops the flood of messages. Every customer who sees that notice is a ticket that doesn't arrive, and mid-outage the team has no one free to answer them.
Say what isn't working, not what failed
"We're experiencing issues with an internal service" helps nobody. "CSV exports are failing; the rest of the product is working normally" does, because each customer can tell whether they're affected.
Almost nobody writes the list of what's still working, and it's the part that reassures people most.
Commit to the next update, not to the fix
"We'll post an update at 11:30" is a promise you can keep. "It'll be fixed within the hour" is one you don't control, and if you miss it, a technical problem becomes a credibility problem.
Then post at 11:30 even if there's nothing new. "Still on it, we know it's the database, next update at 12:00" may look empty, but it tells customers someone is still working on it.
During the outage
Keep the information in one place: a status page, a thread or a channel. If what you say in chat, what goes out on the company account and what the person who emailed hears don't match, the moment two customers compare notes the problem doubles.
Keep the rhythm even when nothing changes. If you said every thirty minutes, post every thirty minutes. Silence always reads as abandonment.
Nobody promises times on their own. Mid-outage, someone on the team, with the best intentions, tells a big customer it'll be back "in half an hour". When it isn't, that customer has a broken promise and the others don't. Set the rule beforehand: times come from the official update and nowhere else.
After: the post mortem
The post mortem answers the third question, whether it'll happen again. Almost everybody skips it, because once the problem is fixed it feels finished.
A good post mortem has four parts:
- What happened, in the customer's terms rather than the system's: "For 1h 47m, exports failed for 30% of accounts."
- Why, with honest detail. It doesn't need a diagram, but it can't sound like an excuse. "A change to how we store files didn't account for accounts with over 50,000 records" is enough, and it's true.
- What you've changed so it doesn't happen again, in concrete terms. "We added a test with realistic data volumes before every deploy" counts. "We've strengthened our processes" means nothing, and everybody knows it.
- What happens for the people affected. If there's compensation, say it here. If there isn't, say that too.
Publishing it openly feels uncomfortable the first time, and over time it's what builds the most trust. A company that explains its outages in detail shows that it looks into them.
The four mistakes that cost customers
1. An apology instead of 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. The reader wants to know whether they're affected and when it'll be back, and has to wade through a paragraph of courtesy without finding out.
Put a short apology at the top and the facts right after it. The order matters.
2. The corporate voice
In an incident, institutional language sounds like a cover-up. "A degradation of service has occurred" and "we've been down for an hour" describe the same thing, and only the second sounds like a person.
3. Downplaying it
Calling it "a small issue affecting some users" when it cost someone their morning is the fastest way to turn an understanding customer into an angry one. If the incident was serious, say so.
4. Only telling the people who asked
This is the most common one on small teams: you reply to the eight people who wrote in and never tell the four hundred who suffered it in silence. Those four hundred are left thinking the product breaks and nobody says anything.
What you can prepare in advance
All of this is much easier when you're not improvising at eleven at night:
- A template for the first notice, with blanks to fill in: what's failing, what isn't, when you'll post next.
- A status page that exists before the first outage and doesn't run on the infrastructure that goes down.
- One person who writes, decided in advance. Two people drafting in parallel produce two versions.
- An automatic notice in the inbox while the incident lasts. It's 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 helps during an incident. It recognizes that the incoming question is about the outage, shares the current status and doesn't pretend to fix it. A system that replies with a generic help article mid-incident makes things worse, because it looks like nobody has noticed.
What customers remember
Almost no customer leaves because of an outage. They leave because of an outage combined with the feeling that nobody was on the other side, and that depends on who writes and when.
Six months later, what they remember isn't that you were down for two hours. It's whether you knew before they did.
Frequently asked questions
When should I announce an incident?
As soon as you confirm it, even if you don't know the cause yet. Aim for ten minutes. If you wait for the diagnosis, customers find out on their own.
How often should I post updates?
Every thirty minutes in a full outage, every hour in a partial one, and always at the time you said you would, even if there's nothing new.
Do I have to publish the post mortem?
It isn't mandatory, but it builds the most trust. At the very least, send it to the people affected. Companies that take it seriously publish it on the status page within 48 hours.
Should I compensate customers?
If you have a signed SLA, give whatever it says, without making them ask. If not, it depends on how serious it was. A free month for someone who lost a morning usually costs less than losing the customer. And if you don't compensate, say so.
Do I need a status page if I'm small?
Yes, and the smaller you are, the more you need it: it's how one person notifies four hundred customers. Host it outside your infrastructure so it doesn't go down with everything else.
