# Build Customer Trust During Software Outages - Published: 2026-10-28 - Author: [Tech Magazine](https://techmagazine.io/author/techmagazine-io.md) - Topics: [Q&A](https://techmagazine.io/qa.md) - Source: https://techmagazine.io/qa/build-customer-trust-during-software-outages/ - Publisher: Tech Magazine ### Replace ETAs With Transparent Update Cadence During an unexpected outage, the single worst decision an engineering team can make is publishing an estimated time to resolution (ETA) before the root cause is confirmed. Every missed ETA damages customer trust far more than the downtime itself. Our strict incident protocol at Gixo is replacing ETAs with an inviolable update cadence and raw diagnostic transparency. We post: 'We are currently diagnosing a degraded connection pool between our Web instances and our primary database. We do not have a confirmed fix yet. We will publish our next operational update in exactly fifteen minutes, even if our only update is what we ruled out.' Customers do not expect complex distributed systems to be infallible, but they expect complete operational honesty. When users see that you operate with transparent system architecture and deliver calm, disciplined diagnostic updates every fifteen minutes, panic evaporates because they know your engineering team is methodically in control. --- ### Explain Customer Impact Before Recovery During a service disruption, I would keep in mind that fixing the software doesn't necessarily mean everything is back to normal for customers. For example, if file uploads failed during an outage, customers may not know whether their files have been saved or need to be uploaded again. I would explain what is working, what we're still checking, and whether customers should try again or wait. I would only give instructions that the team has confirmed are safe. If we still don't know what happened to certain requests, I would say so instead of guessing. I believe this small detail can make a real difference. Customers don't just want to know that the team is fixing the problem; they also want to understand how it affects their work. Being clear about this helps them decide what to do next without relying on promises we may not be able to keep. --- ### Promise the Next Check-In I share only three things during an incident. What customers can see, what we know, and when they will hear from us next. I never share a fix time until the team can name the cause. A typical update reads like this. "Calls from the dialer are failing for some accounts. We have found where the failure starts and are working on it. Your data is safe. Next update in 30 minutes, even if nothing has changed." That last promise is the one I can always keep, so I make it every time. The choice that protects trust most is committing to the next update time instead of the resolution time. Customers can plan around a regular update. They cannot plan around a repair estimate that slips twice. I also avoid two habits. I do not blame a vendor in the first update, because customers care about their own business and not whose fault it is. And I do not write "minor issue" before I understand the scope, since a small word that turns out wrong costs more trust than the outage. After the incident, I send a short written summary that says what happened, what we changed, and how we will prevent a repeat. Customers who see a specific change believe the apology. I should say I am sharing the process we use and not a single dramatic case. --- ### Humanize Support Through Accountable Actions 1\. I view a commitment to actions as better than a promise of results. So while "Our engineers are working on a solution right now and we will post an update by 3pm" is something I can control to happen, "Everything will be back to normal shortly" is a hope that I will convey. How a trader reads a chart and reads a trader's tone online is basically the same. So I also try to acknowledge as quickly as possible that yes, this is costing the trader right now. I have total control in the first hour to offer them any kind of empathy. 2\. In updates we put real names behind them. All our messages (updates, new tickets, closed tickets, etc.) were signed by me or the support lead of CheapForexVPS. In addition to the update, there was a direct reply line to ask follow-up questions. I received a lot of personal messages from clients just to thank me for being honest with them. After the fix (which took a lot less time than expected), the person who sent the update also sent a short summary (a few lines) of what went wrong and what we did to fix it. Service credits were applied automatically as well before even a query was put in for them. The service credit itself wasn't as important as the gesture itself. Most people will stick with a service that treats them with the same respect as they would with friends and family rather than a number on a ticket log. --- ### Assign One Owner for Steady Notices We tell customers what we know as soon as we know it, and we're just as clear about what we don't know yet. When an incident hits, whether it's an outage we're working through or something we're waiting on AWS to resolve, we notify clients immediately: we know, we're on it, and here's what we know so far. We don't speculate on root cause. If we're not certain, we say so. The communication choice that's done the most for trust is naming one person to own every customer update and sending those updates at a fixed interval, 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 erodes trust. Once service is restored, we help clients test their systems, confirm everything's working, and document what happened. The conversation about what changes, such as rearchitecting for high availability, happens after the fire is out. --- ### Acknowledge Risk in Plain Language I'd like to share my golden practice. The outage has already happened; that is a fact. You can't help but accept it. In the first place, customers need acknowledgement (yes, this is a risk for you, but it's the company's accountability on a larger scale). That's interesting; nobody needs a perfect answer immediately. Often, they need to know the team is aware, investigating, and not hiding uncertainty. So the strongest update format is: what is affected, who is affected, what the team is doing now, and when the next update will come. Don't give estimates too early. That often backfires. A safer, more credible message is: "We will provide another update in 30 minutes, even if there is no change." And don't be technically heavy. "Some users cannot complete checkout" is more useful than "We are seeing elevated API latency." Customers trust plain language; technical detail can come later. --- ### Direct Users to Public Status Pages During a service disruption, it is crucial to manage communication effectively by directing users to the public status page for real-time updates. This approach minimizes confusion and reduces the need for manual updates or estimated recovery times, which can often be inaccurate. Publishing incident or maintenance history for up to 90 days provides clients with visibility into the severity of issues and the progress being made toward resolution. This level of transparency allows teams to avoid arbitrary timelines, fostering instant credibility with clients. When unexpected downtime occurs, ensure that an automated alert is sent to subscribers informing them of the issue, without providing an estimated recovery time. By doing so, clients can see that the problem is being addressed, which greatly reduces overall panic and minimizes the volume of support tickets—potentially by as much as 90%. If key clients express dissatisfaction with how an incident has been handled, it is important to document their concerns thoroughly. Engage with the technical team to address all points raised and develop a permanent resolution. Afterward, follow up with clients to share a timeline for the implementation of the permanent fix. This structured approach not only helps in rebuilding confidence but also strengthens long-term client relationships. --- ### Correct Early Assumptions Without Delay The communication choice that preserves trust is correcting the record quickly when an early assumption proves wrong. Teams sometimes feel pressured to defend their first explanation. Customers often respect a clear correction more than a polished but outdated message. The key is to explain what changed and why the earlier understanding was incomplete. For example, if a disruption first appears limited to one group, the assessment should change as soon as a wider impact is confirmed. The change should be explained in plain language rather than hidden behind technical terms. The revised impact and timing of the next update should be stated clearly. This shows that accuracy matters more than appearances and that the team is actively testing its assumptions. --- ### Separate Availability From Data Integrity Possible data issues require different language from ordinary outages, because customers will fill gaps with their own threat model. We separate service availability from data integrity in every update. A system may be unavailable without evidence of unauthorized access, or operating while an integrity question remains under review. That distinction prevents an outage notice from becoming an unsupported security assurance. One choice that preserved trust was stating the evidence threshold for stronger claims. Rather than saying customer data was safe, the update said no indicators of unauthorized access had been identified at that time. This is precise, defensible, and far easier to stand behind if the investigation later changes course. --- ### Keep Every Outage Message Simple The choice I'd defend is committing to the time of the next update and never to the time of the fix. During an outage you know three things for sure: what users are seeing, who's affected so far, and that someone is working on it. Say exactly that. A fix time is a guess dressed up as a promise, and when it slips you've handed people a second problem on top of the first. So the message reads something like: here's what's broken, here's who sees it, we don't have a cause yet, next update at 3:30 whether or not anything has changed. Then you hit 3:30. Even an update that says "still investigating, nothing new" keeps your word, and keeping a small word is what builds credibility during a big failure. I'd also keep one person writing every update, in plain language. Engineers drafting by committee tend to produce hedged jargon, and users can tell the team is guessing. Short, flat sentences read as confident because they only claim what's known. After it's resolved, the follow-up matters more than the first alert. Say what happened, how long it lasted, and what's changing. If you can't yet say what's changing, say that too and name when you will. I've seen a vague promise to "never let this happen again" do more damage than silence. Nobody can support that sentence, and people remember it. --- ### Define Scope and Offer Safe Workarounds During an incident, vague statements like "some users may experience issues" make everyone wonder whether they're affected. We replaced them with a three-line format: who is affected, what they can still do, and what we don't know yet. During a 3-hour API degradation, our first post said, 'Customers using bulk exports are affected. Single exports and dashboards work normally. We have not yet identified the cause and won't estimate a fix time until we do.' We also listed a manual workaround for urgent exports. In a similar incident the previous year, our generic wording led to 520 support tickets, and 27% of customers rated our communication as poor. This time, tickets were 175, and 84% of customers rated it positively. Roughly 38% of affected customers used the workaround, and churn among affected accounts that month was 0.3%, compared with 1.6% before. The lesson: precise scope and honest unknowns build more trust than reassurance. --- ### Response Deleted by User Deleted by user --- ### Use an Independent Status Platform An external status page is ideal for this: something independent from your product where you can keep your users up to date. It's important to stay honest and transparent about the problem. You cannot make promises of timelines or estimations on recovery timelines without fully understanding the problem at hand. That means your first few updates are likely going to be limited to acknowledging that there is a problem, potentially clarifying the scope or the impact of that problem, and transparently sharing that more updates will follow as soon as the team has done their initial investigations. Then it's a matter of consistent and constant updates to keep the user informed. Ideally, there is a split where your technical team can work on resolving the problems at hand, and a marketing or non-technical role can take care of the communication (so that the tech team can keep their focus on actually debugging). --- ### State Facts Before You Name Causes I will be honest about where our experience comes from: not from a communication success, but from incidents where the first explanation would have been wrong. That is the strongest argument I know for promising less early on. Three real incidents from September at Streamrise, with the gap between "something is broken" and "we know why": 1\. On 11 September a routine change to 12 files went to production. In two of them one line silently failed to apply, and one feature started throwing errors: from about 60 to about 1,300 an hour. Code checks passed. We found the cause about 8 hours later, after customers wrote that the service was not working. 2\. On 16 September a hosting provider switched off one of our servers over an unpaid invoice. Our main service moved to other servers within about 20 seconds, but our Russian-language site and one product line that depended on that server were down for 3 hours 10 minutes, until the invoice was paid. 3\. On 21 September a third-party network provider's subscription expired and about 16,000 of roughly 26,000 addresses in one pool started failing. Customers saw slow ramp-up, 3 to 4 hours instead of about 35 minutes. It took us about three days to connect the separate complaints to that one cause. In every case the honest status in the first hour was "something is wrong and we do not know why yet". Any time estimate or cause given then would likely have been wrong. In case 3, an early "temporary slowdown, fixed soon" would have been repeated for three days. So the communication choice I would recommend is a fixed structure that never promises a fix time until the cause is confirmed: - What customers will notice right now, in plain words ("new orders start more slowly than usual"). - What is not affected, if you have measured it. In case 2 the main service kept running, and saying so early would have been true. - What you are checking, and the time of the next update. Promise the update, not the fix. - Name the cause only after you can show it, and say when you found it. A test worth applying to any status message: if this turns out wrong tomorrow, would a customer trust the next one? "We don't know yet; next update at 14:00" passes that test. "Should be resolved within the hour" usually fails it. --- ### Disable Broken Paths and Clarify Access During a service disruption, I tell customers which action is affected before offering a recovery time. If an outside dependency has failed, an early estimate can create a second problem: a deadline the team can't meet. I separate what we've confirmed from what engineers are still checking. When either changes, the customer notice changes too. If we can't support a restoration time, I say that plainly and give people a place to find the next update. One fintech app we built had a wallet connected to a bank API. When the bank connection failed, we used a feature flag to switch off the wallet remotely and sent users a push notification. The flag kept the wallet from appearing usable while its dependency was broken. A notification alone would have been a weak answer if the interface still offered the failing action. I apply the same sequence to a failed payment, identity or data provider. The team first identifies the affected action and checks which other actions remain usable. If there's a safe switch, it disables only the broken path. Then the notice says what's unavailable and where customers should look for another update. One person owns revisions as the diagnosis changes, so an old message doesn't outlive the facts behind it. Publish a restoration estimate only when engineering can stand behind it. Until then, customers need the usable boundary and the next source of information. --- ### Let Agents Admit Uncertainty Clearly Our agents are often the first people a customer reaches when a client's platform goes down. What we've learned is that the update matters less than the promise inside it. Every update covers three things: what we know, what we're doing about it, and when the next update will come. It never includes a fix time unless engineering has committed to one. That "next update" time is the most important part. Customers can live without knowing when it will be resolved. What erodes trust is silence, or a deadline that keeps slipping. Engineering usually can't promise when something will be fixed. Anyone can promise "we'll update you by 3:30, even if nothing has changed" and then keep that promise. Each promise you keep makes people believe the next one. The choice that did the most for trust was letting agents say "we don't know yet" plainly instead of filling the gap. During one client's multi-hour outage, the first instinct was to tell callers it would be "resolved shortly." We stopped that within the hour and switched to: "Engineering is still identifying the cause. I won't guess at a time, but we'll post an update every 30 minutes and I can send it straight to you." Repeat contacts dropped because people stopped calling back to check. And when the fix came later than anyone hoped, we had no broken promises to apologise for. We also keep one source of truth. The status page, agent scripts and social replies all use the same approved update, so a customer never hears three different versions. --- ### Reassure Users About Their Saved Work I stick to three things in an incident message. What we know right now, what we haven't confirmed yet, and the time of the next update. A fix time is a guess until an engineer has found the cause, so I leave it out of the message entirely. The choice I'd keep in every incident post is saying what happens to the user's data. In a food app, someone has just photographed their dinner and is standing there with a plate going cold. Comi's offline queue stores a scan taken with no connection and processes it when the connection returns. Telling people their scan is safe and will finish on its own answers what they actually want to know, which is whether they have to redo it. I also like a fixed update rhythm. A short note every so often is useful even when it only says the cause is still being investigated, because it shows someone is watching. If the gaps are long and silent, people fill them with their own theories about what broke. Plain wording helps too. "We're investigating a problem with scans" is a sentence the team can stand behind while the work is still going on. A promise like "back in an hour" needs evidence that nobody has yet at that stage. --- ### Build Trust Through Predictable Rhythm The worst thing you can say during an outage is "it'll be fixed in 30 minutes." I've done it. It took 4 hours. That was at MyTona, a mobile gaming company with 22 million downloads. A pipeline broke, stakeholders wanted answers, and we gave them a number we pulled from thin air. When the 30 minutes passed, trust evaporated. People stopped believing our updates entirely. Now I'm at Softline Solutions, where I manage a GCP data platform handling 1,500+ client accounts. Last year a BigQuery ingestion failure knocked out reporting dashboards for about 40 accounts. Grafana alerts fired at 3:17 AM. PagerDuty woke the on-call engineer (me). And clients started asking questions before we even knew what broke. Here's what I've learned works: tell people what you know and what you don't. That's it. No guesses, no timelines you can't back up. Our first message to affected clients was simple. "BigQuery ingestion paused at 3:17 AM. We're investigating the cause. Current data is available through yesterday. Next update at 4:00 AM." No promises. Just facts. The communication choice that actually built trust was boring. We sent a short update every 30 minutes, even when we had nothing new. "Still investigating. No new findings. Next update at 4:30 AM." Then again at 5:00 AM. Same format, same cadence. Something interesting happened. Clients stopped calling us. The support queue went quiet. Not because they didn't care, but because they trusted the rhythm. They knew an update was coming. They didn't need to chase us for one. Most teams make the same mistake. They go silent when there's nothing to report. But silence is the thing that makes people nervous. Silence is what makes a VP pick up the phone at 2 AM. You don't need good news to send an update. You just need to be predictable. Tell them what broke, what you're doing, and when you'll check in next. Do that every time, and you'll come out of an incident with more trust than you had going in. --- ### Report Only What You Verified I keep updates simple: what I found, what I changed, what I checked, and what still needs checking. If I don’t know when something will be fixed, I say that. In a recent WordPress case, a critical error stopped the website and login page from loading. After the repair, I checked that the login page opened again without the error. But that did not prove the customer could sign in and use everything they needed. That difference shaped the update I prepared. I explained that the login page was working again and asked the customer to sign in and check their access. I avoided saying everything was fixed because I had not verified that yet. For me, clear limits are part of good support. I’d rather tell someone exactly what I have checked than give them a reassuring answer that goes beyond the evidence. ## Related - [SaaS Incident Communication That Preserves Customer Trust](https://techmagazine.io/qa/saas-incident-communication-that-preserves-customer-trust.md) - [After Hours Calls: How Software Teams Decide When to Wake People](https://techmagazine.io/qa/after-hours-calls-how-software-teams-decide-when-to-wake-people.md) - [Set Honest Delivery Dates in Software Projects Without Losing Trust](https://techmagazine.io/qa/set-honest-delivery-dates-in-software-projects-without-losing-trust.md) - [How Software Teams Keep Critical Knowledge From Walking Out the Door](https://techmagazine.io/qa/how-software-teams-keep-critical-knowledge-from-walking-out-the-door.md)