Salesforce Outage: When a Stuck Login Stops Everything

A login failure in one service can leave booking and other work waiting. Each integration needs timeouts, retry limits, and staff-visible failure states. The Salesforce case below helps you ask vendors which work continues, which work is deferred, and how records are reconciled afterwards.

On 16 September 2026, Salesforce customers in all three of its regions had logins, APIs and integrations failing for up to 11 hours. No attack was involved. Requests piled up behind a slow internal login service, each holding server resources until none were left. The lesson for any business system: every call that waits needs a time limit.

That lesson is older than Salesforce. This incident is useful because it shows the failure so cleanly, and because plenty of small systems in Indonesia are built the same way.

What happened on 16 September?

The disruption started at 12:50 a.m. Pacific time, which is 14:50 WIB, the middle of an Indonesian working afternoon. Salesforce Ben's live coverage tracked the status updates: multiple instances across all regions affected within the first hour (an instance is one of the server clusters Salesforce runs, each hosting a group of customers), a rolling restart tried and abandoned, and a fix validated on a test instance at 3:56 a.m. Pacific.

Finding the fix was the quick part. Rolling it out took most of the day. The Register reported that Salesforce deployed it region by region, restarting instances by hand where the automated fix did not complete, and told customers to clear cached data or restart their sessions. CIO.com put the all-clear at 2:59 p.m. Eastern, about eleven hours after the start. In Jakarta that was close to 2 a.m. the next morning.

The scope was wide. Vantagepoint's admin briefing listed hundreds of instances across North America, Europe and Asia Pacific, covering the core platform behind Sales Cloud, Service Cloud, Agentforce and Data Cloud. Even creating a support case failed. It also landed on the opening day of Dreamforce, the company's own conference, with more than 40,000 people on site and over 200,000 watching online.

How can a slow login take everything down?

Picture a bank branch where every teller has to phone head office to approve each transaction. One morning head office stops picking up. Nobody hangs up, because nobody was told how long to wait. Within minutes every teller is standing with a phone to their ear, the queue runs out the door, and customers who only wanted to deposit cash cannot get served either. The tellers are fine. They are just all busy waiting.

Servers work the same way. Each incoming request occupies a worker, one of a fixed number of slots a server can process at the same time. If that request calls another service and the call has no timeout (a limit on how long to wait before giving up), the slot stays occupied until the answer comes back. When the answer never comes, slots fill one by one, and the server starts refusing work it could have done easily.

Salesforce's own status update described exactly this: "requests are stalling while waiting on a response from an internal login service." Google's SRE book calls the pattern a cascading failure, where one overloaded part drags down everything that depends on it, and thread starvation, running out of workers, is one of its oldest forms.

The uncomfortable part: a slow service does more damage than a dead one. A service that immediately refuses connections releases callers quickly. Other failures, such as dropped packets, can leave callers waiting too. A slow service holds every caller hostage.

One more detail belongs in your own incident process. An early status update blamed an external dependency. Later, according to CIO.com, Salesforce said there was no third-party infrastructure problem. The first explanation during an incident is a hypothesis, not a finding, so wait for the RCA, the root-cause analysis written after the dust settles, before you plan around it.

Why did an old component matter this much?

Salesforce's own update named a legacy login server. That detail pushes people toward the wrong conclusion, which is "replace old stuff." Abbas Jaffery of Info-Tech Research Group made the sharper point in CIO.com's coverage: moving to the cloud does not remove dependencies between components; it makes them harder to see.

A component's age matters less than its position. If every request passes through it, it is critical whether it is ten years old or ten days old.

Small systems have the same shape, just with fewer boxes. Things I see on almost every audit of an Indonesian SME system:

• A login or SSO check on every request. SSO, single sign-on, is the shared login used across several apps. If each page load asks the login server whether the session is still valid, the login server is now in the path of every click.
• A license check at startup or on every action. The vendor's license server is slow for an hour, and your whole point-of-sale freezes.
• A payment status poll without a limit. The payment gateway slows down, and every cashier screen hangs on "checking payment."
• A messaging gateway called inline. Check-in waits for the WhatsApp confirmation to send before it finishes.

Each of these is a single point of failure that does not look like one, because the dependency still works 99% of the time. Mapping them is the same exercise as finding single points of failure before they find you: walk one real transaction from the user's click to the database, and write down every other system it touches along the way.

Where is your own system waiting forever?

Start with the defaults, because they are rarely what you would choose. Python's most popular HTTP library states plainly that requests do not time out unless a timeout is set explicitly. PostgreSQL's statement_timeout defaults to zero, which disables it: a query can run as long as it likes. Code written without thinking about this inherits "wait forever" on its most important calls.

The fixes are boring, and that is their strength:

1. Give every outbound call a timeout. Base it on how the dependency behaves on a normal day: look at the slowest one in a hundred calls, add a margin, and stop there. A login check that normally answers in 80 ms does not need 30 seconds.
2. Give the whole user request a deadline too. If the user will give up after 10 seconds, no call inside that request should still be running at second 11. The SRE book calls this deadline propagation: each layer passes down how much time is left.
3. Retry less than you think. A retry is another attempt after a failure. Retries multiply: if three layers each try three times, one click becomes 27 calls to the bottom layer, and they all arrive exactly when that layer is already struggling. Let one layer retry, cap it at one or two attempts, and use backoff with jitter, meaning each retry waits longer than the last, plus a random spread so thousands of clients do not retry in the same second.
4. Fence off each dependency. Give the login check, the payment call and the reporting query their own limited pool of workers or connections. Engineers call this a bulkhead, after the walls that divide a ship's hull so one leak does not sink the whole vessel. A slow login service can then fill its own compartment and nothing else.
5. Trip the breaker. A circuit breaker works like the MCB in your fuse box: after a run of failures it stops calling the dependency for a short period and returns an error immediately, then tests again. Callers fail fast instead of queuing behind a service that cannot answer.

What can keep working while login is down?

More than most systems allow. The login service is needed to sign in. It should not be needed to stay signed in.

Think of a wristband at a concert. The gate checks your ticket once and puts the band on your wrist. After that, staff inside only look at the band; nobody radios the ticket office each time you walk past the bar. In software, the wristband is a signed session token (a JWT is the common format): the login server signs it once, and every other service verifies the signature locally with a cached public key. If the login server goes quiet, people who are already in keep working. New sign-ins and token refreshes may still fail. Token expiry, revocation, and key rotation must remain part of the security design.

Beyond that, decide in advance what the system does without each dependency:

• Read-only mode when the source of writes is unreachable. Staff can still look up a booking, a customer or a price.
• Queue writes, send later. Put outbound sync jobs in a queue that survives a restart, and let a worker drain it once the other side recovers. The pattern is the same one that keeps webhooks from losing money.
• A paper fallback for the front line. A daily export of today's appointments, rooms or deliveries means the counter keeps moving even when the CRM is gone.

If your company uses Salesforce, or any SaaS, you cannot fix their login server. You do control your side of every integration. The middleware that calls their API needs the same timeouts, retry limits and queue. Otherwise their outage becomes your server running out of workers, with the same failure at a smaller scale.

What should you check after "resolved"?

A vendor declaring an incident resolved means their service answers again. It says nothing about the state of your data. Vantagepoint's post-incident list for Salesforce admins is a good template for any system of record:

• Re-run integrations and data loads that ran during the impact window.
• Look for duplicate records created by automatic retries.
• Check scheduled jobs and automated flows that failed or stopped halfway.
• Spot-check record counts and last-modified times on recent data.
• Confirm that emails and support cases submitted during the outage actually arrived.
• Write down the impact window, the restoration time and which processes were affected.

Duplicates are the expensive item. A retry that created an order twice is a stock problem; a retry that charged a card twice is a customer problem. Idempotency keys, a unique ID attached to each operation so the receiver can recognise a repeat, prevent both, but only if they were in place before the outage. After the fact, reconciliation is the only tool: comparing your records against the other system's line by line until they agree.

Then ask the vendor for the RCA in writing. A good one explains why the failure spread, not only what triggered it, and says what will stop it spreading next time.

A checklist for this week

1. List every outbound call your system makes while serving a user: login, payment, license, messaging, AI, partner APIs.
2. For each one, find the timeout in code or config. Check what "default" means for the library and configuration in use.
3. Set timeouts from normal latency plus a margin, and give each user request an overall deadline.
4. Allow retries in one layer only, with a cap and backoff with jitter.
5. Make sure signed-in users stay signed in when the login service is down.
6. Give each critical dependency its own limited pool of workers or connections.
7. Set statement_timeout for your application's database role.
8. Write the post-outage reconciliation list now, before you need it.

The part that stays true

Outages at this scale make the news because of the logo, not because the cause is exotic. A service slowed down, callers waited without a limit, and waiting consumed everything. Every system that calls another system can fail this way.

A dependency that dies is a clean error. A dependency that stalls takes its callers down with it. The difference between those two outcomes is usually one number in a config file that nobody set.