When Production Breaks: Talking to Clients During an Incident
The technical side of an outage gets all the attention, and it is honestly the easier half. The hard half is that someone's business is standing still while you work, and they know it. How that conversation goes often decides whether the client renews, and it decides it more strongly than the outage itself: a short incident handled with straight talk leaves more trust behind than an uneventful month. Handled badly, it leaves the opposite.
Find out before they do
There is no version of the conversation that starts with the client calling you. Uptime checks on the things users touch (the login page, the main action, the API), plus error alerting with a threshold that ignores one-off noise, are the prerequisite for everything else in this article. If the first sign of trouble is a client's WhatsApp message, the incident has already cost you credibility before it cost them revenue.
The first message
Short, honest, and free of diagnosis. The job of the first message is to answer three questions the client already has: do you know, is anyone working on it, and when will I hear from you again. Something like:
We're aware of an issue affecting checkout on your site since 14:20 EET. Our team is on it now. Next update by 14:50, sooner if we restore service first.
Notice what is not in there. No guessing at causes, because a wrong first guess follows you around for the rest of the incident. No apologies stretched over paragraphs. No jargon. The client does not need "a deadlock in the queue driver"; they need to know whether to unplug the phone, and roughly who is doing what.
Update on a clock, not on progress
The single communication mistake that does the most damage: silence. The developer is heads-down, an hour passes, and the client has spent that hour imagining worse and worse scenarios and refreshing their inbox. An update that says "still working on it, next update at 15:30" is worth more than an update that says nothing while looking for better news. Fixed intervals, even during a long outage, even when nothing has changed. Regular nothing-to-report beats an irregular breakthrough.
Give a time for the next contact rather than a time of restoration. Estimated times of recovery have a nasty habit of becoming promises, and a missed promise during an outage costs double, because now you have two problems.
When it is fixed, say so completely
The all-clear deserves more than "resolved". One paragraph does the job: what broke, how it was fixed, and what changes so it stays fixed. Clients read this closely, and the last sentence is the one they remember:
Checkout was failing for 47 minutes because a storage disk filled up with a runaway log file. The disk was cleared and service restored at 15:08. Monitoring now alerts on disk space below 20%, which would have caught this hours before it affected checkout.
That last line turns an incident into evidence that the relationship makes their service better. If you cannot honestly write a prevention line, write the honest version of it: what you learned and what you are still deciding. Clients deal with ambiguity fine as long as you show your work.
Who hears what
In a studio setting there are two audiences and they need different things. The client's owner wants the plain-language narrative above. Their users (or their customers) want a banner on the site or a status page entry saying service is degraded, posted early, without blaming the vendor of anything. For a SaaS, a status page you can actually update under pressure beats a perfectly written email that arrives late; even a simple hosted status page with three states (operational, degraded, outage) is enough and beats nothing by a mile.
Afterwards, one note
The same day or the next, a short internal note: timeline, cause, what changed, what is still open. This feeds the monthly maintenance conversation, and more importantly it feeds the pattern recognition. One incident is an incident; the third one with the same shape is a conversation about architecture, and that conversation is much easier to open with a written record than with a feeling.
None of this takes more effort than the debugging does. It is a template, a timer, and the discipline to send the boring update on schedule. The outage ends either way; the account's opinion of you is decided by the version with words in it.