Salesforce Outage Began With a Login Service That Stalled

The Salesforce outage of September 16, 2026 is usually described as a global CRM outage. We think the more useful description is the one in Salesforce's own status updates, which show a login service that did not go down but stopped answering in time.

That distinction matters for anyone running a shared authentication or session service. A dependency that fails fast lets its callers move on. A dependency that stalls takes their threads, sockets and memory with it.

This post covers what Salesforce said and when, why a slow dependency is worse than a dead one, three details in the timeline, three questions for your own login service, and the customer-side work that follows a provider outage.

What the Salesforce Outage Status Updates Said, in Order

The Salesforce status record for incident 20004433 records impact from 07:50 to 15:26 UTC. We list the key updates as Salesforce posted them, all times UTC.

• 08:32, the incident was posted, and at 08:45 Salesforce described severe delays, intermittent errors and an inability to access some services across multiple instances in all regions.
• 09:10, "requests are stalling while waiting on a response from an internal login service, which is using up available server resources," with a rolling restart attempted on one instance.
• 09:57, Salesforce said it believed an external dependency failure was affecting the legacy login server, and that its third-party infrastructure provider confirmed no issues on its side.
• 10:01, "We're no longer pursuing restarts as a path to remediation."
• 10:56, a fix was validated on a test instance and a fleetwide rollout began, progressing region by region.
• 12:39, some customers still needed a manual restart of their instance, and at 13:13 Salesforce found the rollout had not fully completed for some instances and began reapplying the fix.
• 14:00, Salesforce reported scheduled jobs not running as expected for some customers who could now access the service.
• 15:39, the remaining impact was narrowed to a subset of Hyperforce instances, with first-party environments not impacted.
• 18:59, the incident was declared resolved as of 15:26 UTC.

The timing made it more visible. The Register reported that the outage hit hundreds of instances worldwide the day after Salesforce opened its annual Dreamforce conference, so we expect many customers learned about it from headlines before their own monitoring.

We checked the record again on 8 October 2026. Its root cause field is still empty, so which dependency failed, what the fix changed and why timeouts did not protect callers sooner remain unstated.

Why a Slow Dependency Is Worse Than a Dead One

A fail-stop dependency returns an error or closes the connection quickly. Its caller can serve cached data, show a clean error or try another path, and most importantly it releases what it was holding and moves on.

A fail-slow dependency accepts the request and then does not answer in time. The caller waits, and while it waits it holds a thread or worker, a socket and whatever memory the request has built up. That is the shape Salesforce described, requests stalling on the login service and using up server resources.

Login sits on the critical path for almost everything, including API calls, page loads and background jobs. When it stalls, the stall spreads to every service that calls it. As an illustration, a server with 200 workers can have all 200 waiting on login within seconds, at which point it cannot serve even requests that never needed a fresh authentication check.

Timeouts are the usual defence, and they often guard the wrong phase. Many clients set a short connect timeout but a long or unlimited read timeout, so a dependency that accepts connections and then goes quiet slips past the check we assumed would protect us. We would audit read and total request timeouts on every call to a shared login or session service, not just the connect timeout.

Google's SRE book describes the general mechanism in its chapter on addressing cascading failures, where thread starvation can cause errors directly or lead to health check failures. It also warns that "High deadlines can result in resource consumption in higher levels of the stack when lower levels of the stack are having problems."

We think this is why fail-slow incidents often last longer than outright crashes. A crash is obvious and gets restarted. A stall looks like load, invites more capacity and more retries, and keeps refilling whatever a restart clears. Our post on context deadline exceeded explains how to read which caller gave up first.

Three Details in the Timeline Worth Noticing

Read closely, the status updates show three operational lessons that apply well beyond Salesforce.

1. Restarts Went From Abandoned to Required

At 10:01 Salesforce stopped pursuing restarts, and by 12:39 some instances needed a manual restart to recover. We read that as consistent with a stall. While the stall continues, a restart only clears held resources for them to fill again, but once the underlying fix is in place, a restart is what flushes the stuck work.

2. A Fleetwide Fix Did Not Apply Everywhere

The 13:13 update says the rollout did not fully complete for some instances, and later updates mention manual restarts where the automated fix had not resolved the issue. At fleet scale, a fix is a process with per-instance verification, not a single action.

3. The Blast Radius Was Revised Downward

Early updates described impact across all regions. By 15:39 Salesforce had narrowed it to a subset of Hyperforce instances, and on September 17 it removed sandboxes from the record. As a customer, we would trust our own integration telemetry over the initial scope, which is often wrong in either direction.

Three Checks for Your Own Login or Session Service

The Salesforce outage is a prompt to test the shared authentication or session service in your own stack. We would run three checks on it.

1. Keep Its Timeout Shorter Than the Caller's Deadline

If the gateway waits 30 seconds for the auth service and the auth service waits 60 seconds for its database, the gateway runs out of workers first. Deadlines should shrink as a request moves down the stack, so the lowest layer gives up before the highest.

2. Isolate Its Capacity From Everything Else

Requests that do not need an auth check, such as health checks and public assets, should not share a worker pool with requests that do. A bulkhead keeps a login stall from making the whole service look dead to its own monitoring.

3. Test What Happens When It Answers Slowly

Most tests cover success and fast failure. Few simulate a dependency that holds a socket open for most of the timeout before answering. We would run that test on purpose and watch what the connection pools and middleware do.

The Customer-Side Aftermath Nobody Writes Down

For teams that depend on a provider, recovery starts when the provider recovers. Salesforce itself reported scheduled jobs not running as expected for some customers, and that is only one part of the work.

• Scheduled jobs, flows and external syncs that should have run during the outage may not catch up on their own, leaving a gap until someone reruns them.
• Integrations that queued work during the outage can all retry at once when service returns, creating a second spike.
• Records captured elsewhere during the outage may sit in a failed queue or be lost, and someone has to reconcile them.

We would keep a post-outage checklist for each critical provider, covering missed jobs, retry backlogs and reconciliation. Our dead letter queue operating manual covers the failed-message side, and the third-party outage triage protocol covers deciding early if a provider is the cause.

The first question during the outage is usually what it broke on your side. Teams can ask that directly with agents that investigate a question from Slack against your own logs and job history, so the answer comes with evidence rather than guesses from headlines.

When Waiting Longer Is the Right Call

Short timeouts are not always better. A deadline that is too short makes some expensive but valid requests fail every time, and failing fast without a retry budget can turn a slow dependency into a retry storm, which our post on retry storm amplification describes.

The SRE book calls picking a deadline "something of an art." We would set it from the dependency's measured latency, give long-running operations their own pool and deadline, and pair every timeout with a capped retry policy rather than simply lowering numbers across the board.

Test How Your Stack Behaves When Login Stalls

The Salesforce outage shows a failure most teams have not rehearsed. A login service that stops answering, rather than one that stops running, can consume every caller's capacity and make recovery slower and messier than a clean crash.

We would test that case before it happens, with a stalled auth dependency in a staging environment and a checklist for the work that follows a provider outage. When something stalls in production, Operate runs dedicated AI agents that investigate root causes with cited evidence and propose fixes for engineers to review.