How Software Teams Build Trust During Outages

When an outage is being investigated, it is still very important to maintain an active line of communication. I would be clear about what we know, what remains uncertain, and when customers can expect another update. Before explaining the issue, it is best to gather what details exist for what happened, who is impacted, and what steps are underway. A best practice that we follow for emergency events, is to create a group chat to connect all internal resources working on the issue for quick communication while still tracking the outage remediation in the support ticket system. This makes updates quick to communicate once details are known, and allows for hearing customers' concerns and providing real-time updates. That approach helps us stay accountable without claiming we know more than we do or promising a resolution before it is confirmed but continuing to keep the communication channels open and updated.

Tell customers what you know as soon as you know it, and be just as clear about what you don't know yet.

When an incident hits, whether it's something we're working through or something we're waiting on AWS to resolve, we notify clients right away: we know, we're on it, and here's what we know so far. We don't speculate on root cause or promise a fix time we can't support. If we're not certain, we say so.

The practice that's made our updates most credible is having one person own every customer update and sending updates on a fixed schedule, whether or not there's news. Account managers, support, and leadership don't each send their own version. If nothing has changed, the update says that. Customers can handle "still investigating," but silence and conflicting messages erode trust.

Once service is restored, we help clients test their systems, confirm everything's working, and document what happened. The bigger conversation about what should change, such as rearchitecting for high availability, happens after the fire is out.

During an outage, customers can handle bad news. What they can't handle is silence or a promise that turns out to be wrong. Our customers run production AI workloads, so when something breaks, they have their own customers asking questions too. The practice that made our updates more credible was separating every update into three parts: what we know, what we don't know yet, and when the next update is coming. That last part is the most important. Committing to a fixed update time, even if the update says "no change yet," keeps people from refreshing a status page in frustration. I also stopped allowing time estimates for a fix until engineers had confirmed the root cause, because a missed estimate costs more trust than no estimate at all. It also helps that our customers can reach our engineers directly. When the person answering a question is the person working on the problem, the answers are more precise and people believe them.

Be honest about what you know, what you don't, and what you're doing next. Start with a brief statement of impact (who's affected, which features), then publish short, regular updates even if the only change is we're still investigating.

That keeps customers informed without overpromising a fix date. From an outage we handled at Cyber Techwear we stopped giving single-time ETAs and instead moved to time windows and clear next-steps: what team is working on it, what users can do as a workaround, and when the next update will come.

That simple change made updates feel credible and reduced support volume.

When a software outage affects customers, the most credible way to communicate uncertainty is to be explicit about what you know, what you do not know yet, what customers should expect next, and exactly when they will hear from you again. In practice, I have found that people tolerate uncertainty much better than vague reassurance. What damages trust is pretending you have a timeline before you do.

As a founder operating SaaS, web, mobile, and API products, the most useful pattern for us has been to send updates in a simple structure: current impact, confirmed facts, unknowns still being investigated, temporary workaround if one exists, and next update time. Even if the update is "we are still investigating," it is still useful when it clearly says what changed since the last message and when the next check-in will happen.

One practice that made our incident communication noticeably more useful and credible was separating observations from assumptions. For example, instead of saying, "We expect this to be fixed soon," we would say, "Image processing jobs are currently delayed for some users. We have confirmed the queue backlog is growing. We are still investigating whether the issue is infrastructure-related or tied to a recent deployment. We will post another update in 30 minutes." That sounds less polished, but it is more trustworthy because customers can see the boundary between facts and ongoing diagnosis.

Another lesson is to avoid changing the tone between updates. If the first message is calm and factual, every follow-up should be the same. Customers read inconsistency as loss of control. We also try to include customer-centered detail, like whether data is safe, whether requests are failing versus delayed, and whether users should retry or wait. That makes the update operationally useful, not just performative.

The biggest credibility gain usually comes from update discipline. A predictable cadence, even before you have a resolution, prevents customers from feeling ignored and keeps you from overpromising under pressure.

Credible outage communication resembles good incident forensics. It distinguishes observations from interpretations, and records when each became known. During intermittent authorization failures, I saw how quickly a plausible explanation could harden into customer folklore. The fix was to make updates evidentiary, state measurements, then identify what remained under investigation.

The practice that endured was versioning customer updates. Each statement carried the source of confidence, whether monitoring data, a reproduced test, or confirmation from a dependent system. When the narrative changed, the next update acknowledged the change plainly and explained why. That discipline prevents quiet backtracking. It gives customers factual footing, which matters more than sounding certain before evidence supports certainty.

Every update I write says what's confirmed, says what's still unknown, and gives a clock time for the next one. That clock time does most of the work. People stop refreshing the status page and stop emailing support once they know when they'll hear from you again, even if the next message is just "no change."

Fix estimates are where overpromising starts, so I don't give one until the cause is identified. Before that, I describe the symptom in the user's own terms. On a mobile app that means something like "photo uploads may fail, retry in an hour." Users want to know whether their data is safe and whether to try again now. Which internal service broke is a detail for the post-mortem.

The pattern I keep coming back to is writing each update for someone with ten seconds and one screen. Impact goes first, then what they should do. If I don't know something, I say "still confirming X" in plain words. That earns trust fast, and a confident guess that gets walked back an hour later burns it. I also keep the same wording for the same status across updates, so a change in the message always means a change in the situation.

The worst thing you can do during an outage is promise a fix time you don't control. The second worst is say nothing until you have answers. Both destroy trust, just in different ways.

For our customers, the stakes are immediate. We run management software for salons and clinics across the Middle East, so when the system has a problem, a receptionist is standing in front of a client who wants to book, pay, or check in. They don't need a technical explanation. They need to know what's happening and what to do right now.

The practice that changed our updates the most: we stopped promising when the problem would be fixed and started promising when the next update would come. "We're investigating and will update you by 2:30" is a promise we can always keep, even when we don't yet know the cause. Customers handle uncertainty well when they know they won't be forgotten. What frustrates them is silence.

Every update follows the same simple structure: what we know, what we don't know yet, and what you can do in the meantime. That last part is the one most companies skip, and it's often the most valuable. Telling a salon to note new bookings on paper and enter them once the system is back gives them back a sense of control.

We also send updates where our customers actually are. For most of our clients, that means WhatsApp, in Arabic and English, rather than a status page they'll never check.

After the incident, we close the loop with a short, plain explanation of what happened and what we changed. Customers don't expect perfect software. They expect honesty, and they remember how you treated them during the problem far longer than the problem itself.

I tell customers what an outage has broken and what we've done to contain it, while keeping an unverified recovery time out of the update. An ETA that slips erodes confidence in the facts we can establish. Customers need a usable account of the current state before anyone can promise when an external service will recover.

A fintech app we built had a wallet that depended on a bank API. When the API failed, we remotely disabled the wallet with a feature flag and sent users a push notification. We controlled the switch and the notification, while the timing of the bank's recovery was outside our hands. Pairing a containment action with a customer message is the practice I would carry into another incident.

The first update should say which function is unavailable, what action we've taken and what users should do now. I'd state a cause only as far as the team has verified it. If we haven't checked the rest of the product, I'd say that we're checking rather than assuring users those functions are safe. Unknown recovery times should be described as unknown. Each later update should correspond to a meaningful change in the state customers face. Once a provider reports that its service is back, I would still check the user path before announcing that the function has been restored.

A feature flag can give engineers a way to contain a failure, but users learn what changed through the notification. Keeping the message tied to a confirmed state gives them something to act on. I would leave any restoration estimate out until the team has a technical basis for it.

Say what you know, say what you don't, and give a time for the next update. I'd leave the fix ETA out entirely, because a guessed time is the line people screenshot later.

The practice I keep coming back to is writing every update in two labeled parts. "Confirmed" holds only what I'd repeat word for word on a phone call. "Still checking" holds the suspects. When a suspect moves up, the update says so in those words, and when one gets ruled out, it says that too. People can watch the picture get clearer, and nobody has to reread a paragraph to find what changed.

The second habit is opening each update with the difference since the last one. If nothing differs, the first line says so and repeats when the next update lands. An update that shows up on schedule with no news still tells people someone is watching the problem.

Then I add one line about their own data, because that's the question underneath every outage message. In a food-scanning app, someone mid-dinner wants to know if the meal they just photographed is gone. A line like "scans you take now are stored on your phone and processed when the connection returns" answers that directly, and it only works if you've checked it's true before you write it.

The practice that made our customer updates credible was a fixed update rhythm that did not depend on having news. During incidents we commit to the next update time and we keep it even when the update is 'still investigating.' Silence is what customers fill with their worst guesses. A short message on schedule, saying what we know, what we do not know yet, and what we are doing next, reads as competence because it is verifiable: we said we would report at a time, and we did.

We also separated two jobs that get tangled in most incident communication. One person owns the technical diagnosis. Another owns the customer message, working from confirmed impact rather than from the engineers' current theory. Theories change hourly during a serious incident, and every changed theory that reached customers becomes a broken promise in their memory. Impact statements age well. 'These reports are delayed, your underlying data is safe, next update at 3 PM' can be said early and never needs retracting.

Afterwards we publish the timeline while the details are still uncomfortable. What we detected, when we detected it, what the fix was. Customers who can read an honest timeline forgive the outage. Customers who got a polished paragraph three days later remember the paragraph, and not kindly.

— Vishnuvardhan Reddy Kaithapuram, Software Development Engineer at Amazon Advertising

1. Make one public page your single point of truth for all updates. As a company, in an outage you're fighting a battle of mixed messages. Support could say one thing, and then you could tweet something different and then send an email to say something else and people will believe none of it. I make a page with the timestamp for every update. I write it in numbers rather than words, i.e. "Some users may see issues" doesn't tell you anything. "Roughly 1 in 10 logins failing in Europe since 14:05" helps people work out whether they've got a problem or not. If I don't know the root cause yet, I say that too and stop guessing. The wrong guess becomes the big headline.

2. A simple written timeline of the incident (when we found it, what we did to try and fix it, what finally worked and what we are going to change as a result) helped more than anything else. In our case the story of the incident was spread across many chat messages and support replies, and people were asking the same questions over and over again for days after the incident. Once we had a single written account of what happened, most of the repeat questions stopped, and people seemed to believe our subsequent updates more. One rule that helped implement this was that once an update was posted, that update would never be deleted or edited without stating the change and why it happened. This way even mistakes were more believable than a static page that was edited silently behind the scenes. Start implementing this today by writing a single paragraph update for an incident and agreeing who will manage the status page. It's free.

Say what still works before you say what's broken.

Since early October, Google Books has been returning zero results for ISBN lookups. No explanation from Google. My Book List, one of my 100+ apps, checks Google Books first. If that fails it tries Open Library, then a paid AI search. Most users haven't noticed a thing. My API bill has.

That only worked because the fallback was decided before anything broke. Same with the message. For each outside service (Apple, payments, hosting, AI models) I try to think through what users would see if it stopped, and have the note ready: what still works, what doesn't, when the next update comes. You don't know the cause yet, so promise a time for the next update. Not a fix.

I build and run these apps myself, and I also advise owners independently on technology decisions. What happens when a vendor fails is one of the first things I look at.