Every system fails eventually, and customers know that. What they judge you on is not whether you had an incident but what it was like to be your customer during one. The companies people stay with are the ones where, within a few minutes, there was somewhere to look that said yes, this is us, we know, here is what we are doing. The companies people leave are the ones where support said everything looks fine on our end while nothing worked.
So publish a status page, hosted somewhere that does not share infrastructure with the thing it reports on. That last point is not pedantry — a status page inside the same cloud account, behind the same load balancer, is a status page that goes down precisely when it is needed. Use a third-party service or a separate provider. It costs very little and it is the difference between a status page and a decoration.
Write the first update before you understand the problem. Teams delay because they want to say something accurate and complete, and by the time they have it, an hour of silence has done the damage. Investigating reports of errors on checkout, next update in thirty minutes is accurate, complete enough, and buys you the quiet you need to work. Then honour the thirty minutes even if the update is that there is no news, because a promised update that does not arrive is worse than not promising one.
Say what customers can and cannot do, in their language rather than yours. Degraded performance on the ingestion service tells a customer nothing. New orders are not being accepted; orders already placed are unaffected and will ship normally tells them whether to phone their own customers. The audience for a status update is a support manager deciding what to tell people, not an engineer, and writing for the wrong reader is the most common failure in incident communication.
Afterwards, publish something. Not necessarily a full engineering postmortem — for many businesses a short account of what happened, what the impact was, and what you have changed to prevent it is enough. What matters is that it exists and that it is honest, including about your own mistake if it was one. Customers who read a company taking responsibility for a bad afternoon generally end up trusting it more than before, which is a counterintuitive but consistent effect.
Two things to decide before you need them. Who is allowed to post an update — it should be more than one person, and it should not require an executive to approve wording at two in the morning. And what your threshold is: post for anything customers would notice, not only for total outages, because a partial failure that you did not report is the one that makes people wonder what else you do not report.
