Communicate Clearly During Cloud Software Incidents to Maintain Trust

I'm Runbo Li, Co-founder & CEO at Magic Hour.
The single most important rule during an outage is: say something before customers have to ask. Silence is what kills trust, not the incident itself. People can forgive downtime. They cannot forgive feeling ignored.
We had a major GPU provider issue earlier this year that knocked out video generation for a chunk of our users. Within minutes, I posted a plain-language status update: "Video generation is down for some users. We've identified the issue. It's on the infrastructure side, not your account. We're working on a fix and will update every 30 minutes until it's resolved." That's it. No jargon, no vague "we're looking into it," no corporate non-answer.
The key decision was the 30-minute cadence. Even if nothing changed, I posted an update saying "still working on it, no new info yet." That sounds redundant, but it's the opposite. It tells your users you haven't forgotten about them. It tells them someone is actively watching. The moment you go quiet, people start imagining the worst, they start flooding your support channels, and now you have two problems instead of one.
The message that reduced confusion the most was one specific line: "It's on the infrastructure side, not your account." That single sentence cut our support tickets during the incident by what felt like half. Because the first thing every user thinks when something breaks is "did I do something wrong?" or "is my project lost?" Answering the unasked question before they ask it is the move.
Here's my framework. First message: what's broken, who's affected, and what it's not. Updates: fixed cadence, even if the update is "no change." Final message: what happened, what we did, and what we're doing to prevent it next time. That last one matters more than people think. It converts an incident into a trust-building moment.
Customers don't expect perfection. They expect honesty delivered on a predictable schedule. That's the entire playbook.

When a major incident hits, communication is not an afterthought to the technical recovery. Instead, it is a parallel workstream that deserves the same engineering rigor. Major incidents differ from routine ones: active, broad communication with stakeholders becomes essential, and in many events the perception created by communication plays an even more significant role in shaping the overall impact than the technical problem and its symptoms. Therefore, what to communicate and how often start to become things the team has to engineer in advance.

Choosing what to say starts with a hard line between what is broken and what is still working. Customers fill silence and vagueness with worst-case assumptions, so every update states impact in simple, jargon-free language: no internal terminology, no architecture tours, no blame shifted onto a dependency the customer never chose. You speak as one organization, as an owner. Before publishing anything, apply a test drawn from the correction-of-error discipline practiced and field-tested by multiple tech companies: if I were the customer reading this, what would I want to ask? Then answer those questions preemptively. Trust comes from demonstrating a deep understanding of what happened and having a handle on it, not from minimizing it.

Communication cadence is a promise to keep. Effective communication has to address four distinct groups: the affected users, the indirectly or potentially affected stakeholders, the internal teams and experts resolving the issue, and management. And every update ends by committing to the time of the next one. "No new news, still fully engaged, next update at 2:30 PM" is a complete and valuable message. Missing a promised update destroys more trust than the outage itself.

Here is a demonstration from a previous event I worked on: within minutes of the major incident beginning, the recovery lead opened a dedicated communications channel and posted a pre-drafted holding message: the impact, what was not affected, and the next update time. Because the template existed before the incident, that first message landed while the engineering team was still diagnosing, and speculation never took root. The follow-through mattered just as much: a plain-language narrative with a detailed event timeline, including at least one corrective action already completed. Moving one step ahead of the customer's questions is what prevents a large-scale outage from becoming a customer trust disaster.

When an incident affects our cloud infrastructure at Distribute, we default to immediate, brief acknowledgment over waiting for a complete technical diagnosis. Early on, when our AI email generation or sending pipelines hit a snag, our instinct was to hold off on messaging users until we knew exactly what the root cause was. We quickly learned that even ten minutes of silence causes much more frustration for founders relying on our system than the outage itself.

Now, our rule for what to say is entirely impact-driven rather than technical. Instead of explaining that a specific API or server node is experiencing latency, we only tell customers exactly how their workflow is affected and what is being done to protect their campaigns. During a recent delay in our sending engine, the message that kept trust intact was simply: "Outbound sending is temporarily paused. Your scheduled emails are safely queued, and no budget will be consumed until the system is fully operational."

We commit to updating that status every thirty minutes during an active event, even if the update is just to say that we are still working on the issue and nothing has changed. Taking the guesswork out of the timeline and confirming that their queued campaigns wouldn't misfire or drain their pay-as-you-go daily budget stopped the support tickets from flooding in and kept friction to a minimum.

Bootstrapping two companies for 6+ years means you eventually face the moment where your SaaS goes down and your inbox fills up faster than your engineering team can diagnose the problem. We had an infrastructure outage at Pageloot that took down QR code scanning for a portion of users. The instinct is to wait until you have answers before saying anything. That instinct is wrong.

The first message we sent went out before we knew the cause. It said something like: we're aware of an issue affecting scans, our team is on it, next update in 30 minutes. That single message cut inbound support volume noticeably because customers stopped writing in to tell us something was broken. They already knew we knew.

A few things we learned from that:
Frequency beats completeness. Customers don't need a full explanation, they need to know you're still working it and haven't gone silent. A short "no new info, still investigating, update in 20 minutes" is better than nothing while you wait for your engineer to confirm a root cause.
Own the uncertainty. "We don't know yet why this is happening" is less damaging than vague corporate language. Founders who hedge with phrases like "some users may be experiencing" when the system is clearly down just make people angrier. Say what you know, say what you don't.
The post-incident message matters as much as the live updates. After resolution, we sent a summary: what happened, how long it lasted, what we changed to prevent it. Most customers who responded said that note actually increased their confidence compared to before the incident. One agency client specifically mentioned it when renewing.
The mistake I see from other bootstrapped products is treating the post-mortem as optional, something you do when the dust settles. It's actually the highest-trust communication in the whole sequence. The outage is the crisis, the follow-up is the recovery.
One thing worth setting up before any incident: a status page or a dedicated communication channel so customers aren't refreshing your main site looking for answers. We lost about 60 minutes of trust on that first outage just because people didn't know where to look.