An outage that started before dawn and outlasted the morning
Salesforce's outage began around 2:50 AM Central time on Wednesday, September 16, with the company rolling out region-by-region restoration starting roughly three hours later, around 6:00 AM Central. As of 8:00 AM Central, deployment of the fix was still proceeding, meaning the practical disruption window for some customers stretched past five hours from initial onset to full resolution, longer than the headline restoration timeline suggests.
That drawn-out restoration pattern, rather than an instant global fix, is itself informative. A region-by-region rollout suggests the remediation required careful, staged deployment rather than a single reversible configuration change, consistent with an underlying resource contention problem that needed capacity to be freed up gradually rather than a flag that could simply be flipped back.
The vague but telling root cause
Salesforce's public explanation was unusually specific about symptom while staying vague about cause: the company stated that requests were stalling while waiting on a response from an internal login service, which was consuming available server resources, and that increased load on a core system component limited capacity. No further explanation followed, leaving customers to infer rather than confirm what actually triggered the login service slowdown in the first place.
An authentication service backing up under load is a specific and recognizable failure pattern: when a login or session-validation service becomes the bottleneck, every downstream request that depends on verifying who is asking gets stuck waiting, regardless of how healthy the rest of the application stack is. That single-point dependency is exactly why identity and authentication infrastructure gets held to a higher reliability bar than most other backend services, and why this incident cascaded across nearly every core product simultaneously.
What broke and what did not
The affected list covers the products most customers interact with daily: Sales Cloud, Service Cloud, Agentforce, Data Cloud, Lightning Platform, Financial Services Cloud, Health Cloud and CPQ and Billing. That Agentforce, Salesforce's flagship AI agent platform, was on the affected list is notable given how central agentic AI has become to Salesforce's product narrative and sales pitch over the past year.
Products that stayed up included MuleSoft, Tableau, Marketing Cloud Engagement, Personalization, Heroku and Experience Cloud, a split that suggests those products run on more isolated infrastructure or at least did not share the specific login service dependency that failed. Customers running integrations that span both the affected core products and the unaffected ones would have experienced a confusing partial-failure state, functional in some systems and stalled in others.
The support ticket problem inside the outage
Support case creation was itself blocked during the outage window, which meant customers experiencing the disruption had no way to formally log it through Salesforce's own normal support channel while it was actively happening. That is a specific and uncomfortable failure mode: the incident took down not just the product but the mechanism customers would normally use to report the incident, forcing reliance on the public status page and word of mouth instead.
For any vendor, a support system that depends on the same infrastructure as the product it supports creates this exact trap during a severe enough outage. Enterprise customers evaluating vendor reliability commitments should ask specifically whether incident reporting channels are architected to stay available independent of the core product's health, since this outage demonstrated what happens when they are not.
Global reach, uneven urgency
The disruption confirmed across the United States, Japan, India, the United Kingdom, France and Germany, spanning all three of Salesforce's operating regions, ruling out a narrow regional infrastructure issue as the sole explanation. GovCloud customers, subject to stricter isolation requirements, were cleared by 7:00 AM Central, ahead of the broader restoration, suggesting that environment's architecture provided at least partial insulation from the shared login service problem.
For admins managing the aftermath, Salesforce's own guidance centered on practical damage control: check instance-specific status at status.salesforce.com, pause non-critical automations and data jobs to avoid compounding errors, communicate realistic timelines to end users, and after restoration, re-run failed integrations, check for duplicate records, and verify recent data given the risk of partially executed transactions during the degraded window.
The Dreamforce timing nobody could plan for
The outage landed on day two of Dreamforce, Salesforce's flagship annual conference drawing more than 40,000 in-person attendees, a coincidence that guaranteed maximum visibility for an incident the company would otherwise have preferred to manage quietly and quickly. Conference attendees demoing Agentforce and other AI capabilities live were doing so, at least for part of the morning, against a backdrop of the same products failing for production customers elsewhere.
For enterprise buyers, the lesson is less about Salesforce specifically and more about vendor reliability commitments during exactly the moments a vendor has the most incentive to look good. Reliability that holds up under ordinary conditions but degrades under real load or bad timing is the pattern enterprise procurement teams should be probing for in SLA negotiations, since a vendor's own high-visibility event is not immune to the same operational fragility as any other Tuesday.
