Customers Give You Three Outages Before They Shop Elsewhere. New Data Says the Trigger Isn't the Downtime.
60% of customers look for a new vendor after three outages, per new survey data — but the real driver is silence during the incident, not the incident itself.
Every SaaS company treats downtime as an engineering metric. Uptime percentage, mean time to resolution, error budgets — all of it measured, reported, and reviewed in a postmortem that almost never mentions the customer's experience of not knowing what was happening while your systems were down. New survey data says that's exactly backwards. The outage isn't what costs you the account. What you told the customer during it is.
The third outage, not the first, is where the decision gets made
Xurrent — an enterprise service management vendor, formerly known as 4me — commissioned Dynata to survey 1,000 U.S. adults in spring 2026 about how they actually respond to service disruptions from software vendors. The headline number is the one above: three outages is the point where a majority of customers stop giving a vendor the benefit of the doubt and start actively comparing alternatives. Not the first. Not even necessarily the second. The third.
That threshold matters because it changes what "acceptable" reliability actually means in practice. Most SaaS teams set an internal bar — 99.9% uptime, say — and treat any incident under that bar as a rounding error the business shouldn't worry about. But customers aren't counting uptime percentage. They're counting incidents, and specifically they're counting how many times in a row your product has interrupted their work. A single bad afternoon is forgivable. A pattern is a decision.
Xurrent CEO Brian Wenngatz put it plainly in the release announcing the data: "Customers don't care if you closed a support ticket in record time when the exact same system crashes again next week." That's the mechanism in one sentence — a fast resolution on incident three doesn't undo the fact that it's incident three. Speed of the fix and tolerance for the pattern are two completely different variables, and most incident response programs are optimized entirely around the first one.
What customers are actually reacting to isn't the outage
If duration and resolution speed aren't the trigger, the survey data points at something more specific: silence. Thirty percent of respondents said they got zero useful information during their most recent service disruption. Thirty-four percent said they had to go looking for updates themselves rather than being proactively told anything. Put those together and roughly a third of customers experiencing an outage today are functionally in the dark for the entire duration of it — not uninformed about the fix, uninformed about the fact that anyone is even working on it.
That gap reads differently depending on who's experiencing it. Gen Z respondents in the same survey were considerably less patient with communication gaps than older cohorts, and considerably more demanding about response speed generally — which matters if your customer base or buying committee skews younger, as most PLG and mid-market SaaS increasingly does.
| Expectation during an outage | Gen Z | General population |
|---|---|---|
| Want an immediate, automated response the moment an outage starts | 65% | 48% |
| Say trust erodes fastest when a company fails to provide updates | 25% | 18% (Baby Boomers) |
Source: Xurrent, commissioned survey by Dynata, Spring 2026.
Neither of those questions is about how fast the underlying bug got fixed. Both are about whether the customer was told anything while it was being fixed. This is the same pattern we've written about in support-driven churn — resolution speed isn't what customers are actually reacting to, being left without information is. An outage is a support ticket the entire customer base opened at once, and most incident response processes still route it through engineering channels only, with nothing built for the customer-facing half of the problem.
The number behind the number: $600 billion and rising fast
Xurrent's survey captures customer sentiment. Splunk and Oxford Economics captured the balance-sheet side of the same problem in a May 2026 report, surveying 2,000 executives at Global 2000 companies across 20 countries and nine industries. Their headline figure: downtime now costs those companies $600 billion annually in aggregate, a 50% jump from the same survey run two years earlier. Average lost revenue per organization hit $95 million a year — nearly double the 2024 figure — with an average cost of $15,000 per minute of downtime.
Source: Splunk and Oxford Economics, "The Hidden Costs of Downtime," May 2026 (2,000 Global 2000 executives, 20 countries).
Two numbers in that chart are worth sitting with together. Eighty-one percent of technology leaders say downtime costs them customers — that's not a surprising admission on its own. But 47% also say customers detect degradation before their own team does, which means for close to half of these companies, the clock on "how long has the customer been experiencing this with no word from us" starts running before the incident is even confirmed internally. Every minute of that gap is a minute the customer spends assuming nobody knows or nobody cares, which is precisely the condition the Xurrent data says erodes trust fastest.
The gap between mature and immature incident-response organizations in that same Splunk report is the most actionable number in it. Companies with what the report calls AI-workflow-mature incident response — meaning automated detection, automated customer notification, and structured escalation rather than someone manually drafting a status page update mid-incident — reported never losing a customer to downtime at nearly three times the rate of less mature organizations. That's not a claim that AI tooling prevents outages. It's a claim that it prevents the silence, and the silence is what the churn model above says actually costs you the account.
Building the three-strike signal into your churn stack
Most companies track outage history as an engineering artifact — a postmortem doc, an incident retro, maybe a status page archive nobody revisits. None of that connects to churn analysis by default, which means the exact pattern the Xurrent data says predicts a cancellation (three incidents, same account, recent window) usually isn't visible anywhere a retention team would look. Three changes close that gap without new infrastructure:
- Count incidents per account, not just per system. Your status page tracks system-wide outages. What predicts churn is how many of those outages a specific customer actually experienced — which depends on their usage hours, region, and which services they depend on. An account that's been through three incidents in 90 days is a different retention risk than one that's been through zero, even if your platform-wide uptime number looks identical for both.
- Feed that count into whatever health score you're already running. We've written about why most health scores fail to predict cancellation — usually because they're built from lagging, easy-to-pull signals instead of ones that actually move before someone decides to leave. Incident count is a leading indicator most scores are currently missing entirely, and it's sitting in your status page tooling already.
- Trigger proactive outreach at incident two, not after the cancellation. If the data says three incidents is roughly where most customers start shopping, the second incident is your last window to intervene before that decision is made. A short, specific message — acknowledging the pattern, not just the individual incident, and saying concretely what changed as a result of the first one — does more to retain that account than any discount offered after they've already clicked cancel.
When an outage-driven cancellation does reach your cancel page anyway, treat it the way we've argued support-driven cancellations should be treated: not with a generic discount, which reads as tone-deaf to someone leaving because your product broke on them repeatedly, but with a direct acknowledgment and a specific answer to what's changed. A cancel reason survey that includes "reliability" or "outages" as its own option, distinct from "technical problems" generally, gives you the data to know whether this is happening at meaningful volume before it shows up as an unexplained dip in renewal rate three months from now.
None of this requires predicting or preventing every outage — that's not realistic for any company running production software at scale. What it requires is treating incident communication as retention infrastructure rather than a courtesy, and tracking the pattern at the account level instead of only the system level. Run your last two quarters of churn against your incident history and see how many cancellations line up with an account's third unexplained outage — it's usually a bigger number than the postmortems suggest, and unlike most churn causes, it's one almost entirely inside your own control. If that overlap turns out to be meaningful, our churn calculator will tell you what closing it is actually worth, and a cancellation flow that recognizes an account's incident history before it renders a generic save offer is the last chance to catch that customer before the third strike becomes final.
Frequently asked questions
How many outages does it take before customers start looking for a new vendor?+
Three, according to a June 2026 survey Xurrent commissioned from Dynata: 60% of respondents said they'd actively seek an alternative provider after three service outages from the same vendor. That's a threshold, not a hard rule — a single catastrophic outage can push a customer out the door on its own — but it tells you the first outage usually isn't the one that costs you the account. The second and third are where the decision actually gets made.
Is downtime itself what drives customers to churn, or something else?+
The data points at communication, not downtime duration. In the same Xurrent/Dynata survey, 30% of respondents said they received zero useful information during their last service disruption, and 34% said they had to go looking for updates themselves instead of being told. Two outages of identical length can produce very different churn outcomes depending on whether the customer was kept informed or left to guess.
What does downtime actually cost a SaaS company beyond the outage itself?+
Splunk and Oxford Economics surveyed 2,000 Global 2000 executives across 20 countries in May 2026 and put the aggregate annual cost of downtime at $600 billion — up 50% from the same survey two years earlier — with an average of $95 million in lost revenue per organization. Separately, 81% of technology leaders in that survey named customer loss as a direct consequence of downtime, and 47% said customers are often or very often the first to notice degradation, ahead of their own monitoring.
How do I reduce outage-driven churn without eliminating outages, which is impossible?+
Treat incident communication as its own workstream, separate from the incident fix. That means a status page that updates automatically as severity and scope change, a notification the moment you have anything to say (even "we're aware and investigating" beats silence), and internal tracking of how many incidents each account has been through in the last 90 days so a third outage triggers proactive outreach before that customer reaches your cancellation flow on their own.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →