Salesforce went down worldwide on September 16, tripping up customers from Amazon to Toyota for roughly three hours, right as the company's own Dreamforce conference was getting underway a few miles from its San Francisco headquarters. Salesforce traced the failure to its internal login service, which choked on incoming requests and burned through server capacity across hundreds of customer instances before engineers rolled out a fix region by region.
The timing could not have been worse for the company. More than 40,000 people were on the ground at Dreamforce and another 200,000-plus had registered to watch online, meaning Salesforce spent the morning of its biggest marketing event of the year fielding a global support meltdown instead.
RelatedAmazon Is Shutting Down Mechanical Turk After 21 Years
What actually broke?
Salesforce's own Trust status page flagged trouble with its Core Service starting around 7:50 UTC, with the outage becoming widely visible closer to 8:30 UTC (9:30 BST, 1:30 AM Pacific). Customers across the US, Japan, India, the UK, France and Germany hit severe delays, intermittent errors, and, in a detail that made triage harder for everyone involved, an inability to file new support cases through Salesforce itself. Downdetector-style reports split roughly 69% website, 16% app and 15% login failures, which lines up with a login-layer problem rather than a full data center loss.
What caused it?
Salesforce's engineers said requests were stalling while waiting on a response from an internal login service, and that pileup of stalled requests was what actually consumed the available server resources, not a single crashed data center. The company later refined that explanation: increased load on a core system component had constrained its own capacity, effectively a chokepoint that every authenticated request had to pass through before it could reach an org's data.
How did Salesforce fix it?
Rather than a blind restart, Salesforce validated a fix on a test instance first, then rolled it out fleetwide on a region-by-region basis, with GovCloud customers recovering first. That rollout began around 10:56 UTC (12:19 BST), roughly two and a half hours after the first reports. The core disruption is widely reported at about two hours and forty-three minutes, though recovery for the long tail of smaller instances stretched further, since a staged rollout by design leaves some customers waiting while others are already back online.
- ~7:50 UTCSalesforce Trust status first flags Core Service issues. Not yet widely reported.
- ~8:30 UTCOutage becomes global and visible. Hundreds of instances across 6+ countries affected.
- ~10:56 UTCFix validated and rollout begins. Region by region, GovCloud first.
- ~11:13 UTCCore disruption ends for most customers. About 2h43m after it started.
- Later Sept 16Rolling recovery continues for remaining instances. No single confirmed all-clear time.
Who got hit?
Salesforce doesn't publish a customer list, but reporting during the outage named Amazon, Walmart, Coca-Cola, Toyota and IBM among the enterprises affected, a reminder of just how much of the Fortune 500 runs its sales pipelines, support desks and marketing automation on Salesforce's stack rather than something they built or host themselves. An outage there doesn't just annoy Salesforce's own admins. It stalls whatever business process each of those companies bolted on top of it, from support tickets to order tracking.
| Incident | Salesforce, Sept 2026 | Microsoft 365, July 2026 | AI chat outage, Sept 2026 |
|---|---|---|---|
| Root cause | Internal login service overload | Maintenance bug | Simultaneous multi-model errors |
| Scope | Hundreds of instances, 6+ countries | Global tenants | Multiple providers at once |
| Core downtime | ~2h43m, then staged recovery | Hours, regional variance | Under two hours |
| Fix approach | Region-by-region rollout, GovCloud first | Root-cause patch + rollback | Independent provider fixes |
Why did it land during Dreamforce?
There's no evidence the conference itself caused the outage; Dreamforce doesn't run on the same production infrastructure as customer orgs. But the optics are brutal regardless of cause. Salesforce spent September 16 trying to sell 40,000 in-person attendees and 200,000 online viewers on Agentforce and its broader AI pitch, while its own support channels were failing for the exact enterprise customers that pitch targets. A vendor asking a room full of CIOs to trust it with more of their operations has a much harder case to make the same morning its login layer buckled.
RelatedPayPal Stock Drops 13% as Stripe-Advent's $50B Bid Collapses
What does this mean for the stock?
Salesforce trades as CRM on the NYSE, and single-day outages rarely move a stock this size by themselves unless they extend into a pattern or start showing up in churn numbers. The more concrete signal for investors to watch is whether this becomes a recurring line item: Salesforce has had isolated availability incidents before, and one clean, well-communicated three-hour outage during a marketing event is a bad news cycle, not a structural problem. A second or third incident inside the same quarter would be the point where analysts start asking about reliability spend on the next earnings call.
- Post-incident report. Whether Salesforce publishes a detailed root-cause writeup naming the specific component that overloaded, the way major cloud providers now routinely do after big outages.
- Recurrence. A single login-service bottleneck taking down every region at once is a single-point-of-failure design question, not just a one-off bug; watch whether Salesforce discloses architecture changes to decouple regions.
- Enterprise contracts. Whether any of the named customers, Amazon, Walmart, Toyota, Coca-Cola or IBM, push for stronger SLA terms after a Dreamforce-week failure this visible.
Our take
The mechanism here is the actual story, not just the downtime. A login service that every region's requests have to pass through is a textbook single point of failure, and it took down customers on three continents at once precisely because it was shared infrastructure rather than a regional one. Salesforce's region-by-region recovery, GovCloud first, was the right call operationally. It just doesn't fix the underlying shape of the problem, which is that one internal service being slow can still, in 2026, take an entire global SaaS platform down for the better part of a morning.
- OfficialSalesforce Trust Status: incident 20004433 (Salesforce's own incident record)
- ReferenceThe Register: Salesforce suffers global outage amid Dreamforce shindig (timeline, root cause and customer impact reporting)
Original analysis by GenZTech, based on Salesforce's Trust Status incident record and contemporaneous reporting.
