On September 16, 2026 — the second day of Salesforce's own Dreamforce conference in San Francisco — Salesforce went down for customers across multiple regions. Logins failed, support cases couldn't be filed, and instances in the US, UK, Germany, France, India and Japan were affected for hours. Salesforce's status updates traced the failure to an internal login service: requests to it were stalling, and those stalled requests consumed available server resources — and a later update blamed "an external dependency failure that's impacting the legacy login server." Salesforce's status page lists the impact window as 07:50 to 15:26 UTC (about seven and a half hours), with the incident formally marked resolved at 18:59 UTC. Salesforce has said a full investigation of the underlying cause is still to come.
What happened, in sequence
According to Salesforce's Trust status page (incident 20004433):
- ~07:50 UTC — Impact begins; customer-facing services start failing across multiple instances.
- 08:32–08:45 UTC — Salesforce opens the incident publicly, describing an issue "impacting multiple instances across all regions" with severe delays, intermittent errors, and inability to access some services. Customers also couldn't submit new support cases through the Help portal.
- 09:10 UTC — Salesforce names the mechanism: requests were stalling while waiting on a response from an internal login service, which was consuming available server resources.
- 09:57 UTC — Salesforce says it believes an external dependency failure is impacting the legacy login server, and that its third-party infrastructure provider has confirmed no issues on its side.
- 10:18–10:56 UTC — Salesforce says a core system component experienced increased load that limited its capacity; a fix is tested and validated on a test instance.
- 11:19 UTC — Fleetwide rollout in progress; customers start seeing recovery. The rollout later has to be reapplied on instances where it didn't complete.
- 15:26 UTC — Impact ends; Salesforce later narrows the remaining impact to a subset of Hyperforce instances and says the impact radius was narrower than first understood.
- 18:59 UTC — Incident formally closed.
The outage landed on day two of Dreamforce 2026 (September 15–17 at Moscone Center), an event The Register said had more than 40,000 people attending in person and 200,000+ registered online.
The actual engineering problem
Strip away the timing coincidence with Dreamforce, and the technically interesting part is the mechanism Salesforce described in its own updates: a legacy login server, hit by an external dependency failure, started stalling. It didn't fail cleanly — requests waiting on it held on to server resources, and that resource exhaustion spread into services beyond login itself. Salesforce hasn't yet published the full root cause, so the finer detail of why the dependency failed is still unknown.
This is a well-understood failure mode — a dependency's age and position in the request path matter more than how well-isolated or modern the rest of the architecture is — but it's rare to see it play out at this scale, on one of the largest enterprise SaaS platforms, in near-real-time during a major public event. Multiple outlets covering the incident (Computerworld, CIO) framed it explicitly as an argument that cloud dependency chains — including a vendor's own internal ones — carry risk that isn't visible from outside, and that isn't necessarily reduced just because the vendor is large and mature.
Is this actually notable, or just a bad day?
Vendor outages happen constantly, and most aren't worth writing about. This one is worth flagging for three concrete reasons: the blast radius spanned multiple regions and services (access to the platform and the support-case portal failed together, which is itself a design smell — your incident-reporting channel shouldn't share a failure domain with the thing it reports on); the mechanism Salesforce named was a concrete architectural pattern (a legacy login server that other requests blocked on) rather than a vague "network issue"; and it happened to one of the most heavily used enterprise SaaS platforms in the world, meaning a large number of downstream businesses had their own operations — sales, support, order processing — stall in sympathy for hours, with little they could do on their side to route around it.
Nothing Salesforce has published points to a security breach or data loss — it restored service within hours and kept a detailed public timeline. It's a reliability and dependency-management story, not a security one.
What this changes
For engineers building on top of Salesforce or any single-vendor SaaS platform, this incident doesn't offer a new mitigation — there generally isn't one, since you don't control the vendor's internal login path. What it does change is worth acting on:
- Audit your own auth paths for the same pattern. If your platform has an old, rarely-touched authentication or session-validation service that newer microservices call into, ask what happens when it stalls rather than errors — a slow dependency that holds connections open is often more dangerous than one that fails fast, because it eats resources instead of releasing them.
- Don't co-locate your status/support channel with the system it reports on. If your incident communication tooling depends on the same login service as your product, an outage removes your ability to tell customers what's happening at the exact moment they need to hear it.
- Push for, and design around, explicit timeouts and circuit breakers on internal dependencies — including ones that have been stable for years. Age is not a reliability guarantee; it's often the opposite, since old components accumulate undocumented load-bearing status nobody re-evaluates.
- If your business runs critical workflows through a single SaaS vendor with no viable failover, treat that as a known risk to plan around (manual fallback processes, cached read access, clear customer communication) rather than an unlikely edge case.
If you're evaluating whether a workflow needs custom-built resilience instead of leaning entirely on a single vendor's platform, that's the kind of architecture question Wise Hustlers works through with clients — see our cloud and DevOps services.
Sources
- Incident Details — Salesforce Trust Status
- Salesforce staggers back to feet after global outage — The Register
- Salesforce Hit by Global Service Disruption During Dreamforce 2026 — Salesforce Ben
- Salesforce Global Outage Hits Customers on Second Day of Dreamforce — Channel Insider
- Salesforce's massive outage exposes the hidden risks of cloud dependencies — Computerworld
- Salesforce's massive outage exposes the hidden risks of cloud dependencies — CIO