Salesforce's 16 September outage: a stalled login service and the dependency nobody lists

On 16 September 2026, Salesforce customers across all regions ran into severe delays, intermittent errors and an inability to reach some services, and some could not submit support cases through the Help portal. Salesforce's own incident record puts the start of impact at 07:50 UTC and the end at 15:26 UTC, a little over seven and a half hours, and the incident was declared resolved at 18:59 UTC once telemetry had held steady. It happened during Dreamforce 2026, Salesforce's own conference in San Francisco. At 09:10 UTC the company gave its first account of the cause: "requests are stalling while waiting on a response from an internal login service, which is using up available server resources."

That sentence describes one of the oldest failure patterns in distributed systems. It is worth reading carefully, because the same pattern is almost certainly sitting somewhere in your own stack.

What Salesforce's own updates say, in order#

Coverage summarised this as a login outage. The status updates tell a more useful story when read in sequence. All times are UTC, taken from Salesforce's incident record.

• 08:45. First update: an issue "impacting multiple instances across all regions", with some customers unable to submit support cases.
• 09:10. Requests stalling on an internal login service and consuming server resources. A rolling restart is attempted on one instance.
• 09:57. Salesforce says it believes the issue is "caused by an external dependency failure that's impacting the legacy login server", that it is blocking an API endpoint as a potential mitigation, and that its third-party infrastructure provider has confirmed there are no issues on its side.
• 10:01. "We're no longer pursuing restarts as a path to remediation."
• 10:18. "One of our core system components experienced increased load, which limited its capacity to process requests."
• 10:31 to 11:19. A fix is tested on a test instance, validated, and rolled out fleetwide, region by region. GovCloud is confirmed out of impact at 11:41.
• 13:13. The rollout "didn't fully complete for a number of instances". The fix is reapplied, and some customers are told to clear cached data or restart their session.
• 14:00. Manual restarts where the automated fix did not resolve the issue, and reports of "scheduled jobs not running as expected" for some customers who could now log in.
• 15:39. Impact narrowed to a subset of Hyperforce instances. "First-party environments were not impacted."
• 18:59. Declared resolved, with a commitment to establish "the technical trigger, the underlying cause, and preventive action".

A follow-up on 17 September removed sandboxes from the affected list. Even after that and the narrowing on the day, the record still lists 595 instances, with country prefixes running from Australia, Brazil and Canada through India, Japan and Sweden to the United States, and including two in the United Arab Emirates.

As of 30 September, the root cause, action plan and path to resolution fields in the public record are still empty. Everything below is about the pattern the updates describe, not a claim about Salesforce's internals.

A slow dependency is worse than a dead one#

When a dependency is down, calls to it fail immediately. That is bad, but it is cheap. The caller gets an error, releases whatever it was holding and moves on.

When a dependency is slow, calls to it wait. Each waiting request holds a thread, a connection or a slot in a pool while it waits. If the dependency sits on the path of most requests, and a login service sits on the path of almost all of them, the pool fills with requests that are never going to succeed. Every other request on that server then queues behind them, including requests that never needed the slow dependency at all.

That is what "using up available server resources" usually looks like from the inside. It also explains why restarts tend not to help in this kind of incident. A fresh process has an empty pool, and it fills again in seconds for the same reason. I do not know whether that is why Salesforce stopped pursuing restarts at 10:01, and its RCA may say otherwise, but it is the textbook reason.

The defences are also well known, and none of them are new:

• Timeouts on every outbound call, set from what the caller can afford to wait rather than from a library default.
• Bulkheads, meaning separate pools per dependency, so one slow service can exhaust its own allowance and nothing else.
• Circuit breakers that stop calling a dependency once it is clearly unhealthy and fail fast until it recovers.
• Load shedding, deliberately refusing some traffic to protect the rest. Blocking an API endpoint, which Salesforce did at 09:57, is a form of it.

Nobody lists the login service#

Ask a team for its critical dependencies and you will hear about the database, the queue, the payment provider and the email service. You will rarely hear about authentication. It feels ambient, like DNS: part of the floor rather than a component with its own capacity and failure modes.

It is also on the hot path of nearly every request, which makes it one of the most dangerous things in the system to have slow. The word "legacy" in the 09:57 update matters for the same reason. Old authentication paths tend to survive because they are load-bearing for something, and they tend to be the least exercised under unusual load.

Salesforce was not alone in the past few weeks. Microsoft's Exchange Online outage, which began on 31 August and ran until 3 September, was attributed by Microsoft to "core authentication configuration issues used by multiple internal services". And on the same day as Salesforce, Microsoft opened incident MO1472904 for users unable to access some Microsoft 365 services, with reports of 502 and 503 errors and no root cause given at the time.

The point is not that either vendor is careless. It is that authentication is infrastructure, and it deserves the same dependency analysis as anything else you would draw on an architecture diagram.

Recovery was its own incident#

The part of the timeline I would underline for anyone running operations on SaaS is everything after the fix. The rollout did not complete everywhere. Instances needed manual restarts. Sessions and cached data needed clearing. And once customers could log in again, Salesforce itself flagged scheduled jobs not running as expected. Salesforce Ben reported one user whose integrations were "alarming constantly" during the disruption, and others describing callback backlogs.

For the customer, the outage does not end when the status page turns green. It ends when every job that should have run has run, every record that should have synced has synced, and every integration that retried has not created duplicates. That work falls entirely on the customer, and it is usually improvised.

What belongs in a continuity plan when your operations run on SaaS#

None of these depend on the vendor, which is the point. They are the parts you control.

1. Know how you will find out. Salesforce publishes its incident data through a public status API as well as the status page, so the record quoted here can be read by a script as easily as by a person. Know which instance your organisation is on, and alert on it rather than waiting for a user to report that the CRM is slow.
2. Make your own integrations fail fast. The pattern that hurt Salesforce can hurt you in mirror image. If your middleware calls Salesforce with no timeout, your workers stall exactly the way its servers did. Set timeouts, queue writes you can retry, and make every retry idempotent. I wrote more about why this is harder than the API documentation suggests in enterprise integrations in the real world.
3. Keep a reconciliation list. Write down, before you need it, every scheduled job, flow and integration that must be checked after an outage, and who checks it. A push history, which the SAP Ariba connector I built keeps for exactly this kind of after-the-fact diagnosis, is what makes that check possible rather than a guess.
4. Give front-line staff a manual path. Seven and a half hours is a working day. Decide in advance what the service desk, the sales team or the operations floor does when the system of record is unreachable, and what minimum data they need to have somewhere else to do it.
5. Map the login path. Know whether your users reach the platform through your own identity provider, the vendor's login, or both, and what the break-glass route is if either one is the part that fails.
6. Ask for the RCA. Salesforce has committed to identifying the trigger, the underlying cause and the preventive action. Read it when it arrives, and read it against your contract and your own plan.

This is the same argument I make about understanding your production stack: you do not need to run the infrastructure to be responsible for what happens to your business when it fails.

What I would watch next#

The RCA is the thing to wait for, and two lines in the timeline are worth checking against it.

The first is the tension at 09:57 between "an external dependency failure" and the statement, in the same update, that the third-party infrastructure provider confirmed there were no issues on its side. The final account will have to say what the external dependency actually was.

The second is the commitment in the updates to "a code-level permanent fix" and, later in the day, to "preventive protections to related service paths". Whether those protections are timeouts, isolation of the legacy login path, or its retirement will say a lot about how Salesforce thinks about this class of failure. It is also a useful prompt to ask the same question of your own systems before a slow dependency asks it for you.