Requests stalled waiting on an internal login service
A Salesforce disruption surfaced around 0930 BST on September 16 and hit hundreds of instances across the United States, Japan, India, the United Kingdom, France and Germany, according to The Register's report by Lindsay Clark. The status update Salesforce posted is the part worth reading twice. Requests were "stalling while waiting on a response from an internal login service, which is using up available server resources."
A further update said customers "continue to experience severe delays, intermittent errors, and inability to access some services." Salesforce later said the impact was narrower than first understood and affected a subset of Hyperforce instances. Nothing beyond that status language has been published about cause, so everything past it is inference, including ours.
How long it lasted depends on who you read. The Register records resolution declared at 1920 UTC. Salesforce Ben and Channel Insider report a fix rolling fleet-wide by 4:19 a.m. PDT. We are not picking one. If you write this into an incident summary, cite the source next to the number.
Every integration and every agent signs in first
The status language describes a resource problem inside the sign-in path. Requests queued against a login service, that service consumed the server resources available to it, and the symptom reached users as delays and errors in front of the applications they were trying to open. On that reading, the applications sat downstream of the problem rather than causing it.
The ordering matters for anyone drawing a dependency map. Middleware authenticates on a schedule and refreshes tokens. Overnight extracts authenticate before they read a single row. Every agent that touches a record or calls another system authenticates first, and an agent running without a person watching signs in far more often than the person would.
An application tier under load degrades unevenly, and some work still completes. A saturated sign-in path stops everything at the same moment, including the retries and the monitoring aimed at it. Anyone who has run identity work across platforms recognises the shape from single sign-on incidents, and this one sat inside a vendor's own estate where no customer could reach it.
Most continuity plans assume the failure is yours
Continuity plans get written for failures the organisation controls. A server, a network, a release that went out wrong. An upstream outage takes away the part those plans quietly rely on, which is the ability to do something. You wait, you post updates, and you answer the question about restoration with a link to a status page.
The planning question that survives is narrower. For every process that runs through the platform, decide now which of three states it lands in when sign-in stops answering. Some work carries on offline because a person already has what they need. Some work queues safely and replays later without loss. Some work fails without telling anyone, and that third group is what costs money the following week.
Silent failure lives where a send reported success and nothing confirmed a receipt. A scheduled export that wrote an empty file and logged a green run. A consumer that dropped events with nowhere to park them. Error handling that pages a named person is dull work that earns its keep on exactly this kind of morning.
Your own retries can slow the recovery down
Teams underestimate their own contribution to the second hour. When a login service is short of resources, a fleet of integrations retrying on a tight loop adds load to the component least able to absorb it. Recovery then runs slower than it should, and from outside nobody can separate a vendor still broken from a vendor being hit by its own customers.
Go and read the retry configuration on your Salesforce connections before you need it. Check that backoff is exponential and capped, that jitter stops ten thousand jobs waking in the same second, and that something gives up after a bounded number of attempts instead of retrying forever. Check what token refresh does on failure, since a refresh loop against a struggling login service adds exactly the load it cannot take.
Check the way back as well. A queue released in one go can push a recovering system under again. A staged resume, oldest first and rate limited, keeps the return from becoming a second incident. That decision belongs in the first thirty minutes of a platform incident, written down in advance rather than argued about live.
The timing invites a cheap point and a better one
This landed during the week Salesforce was on stage describing agents that work autonomously across the business. The joke writes itself and earns nobody anything. Every large platform has outages, including the ones your own team runs, and grading a vendor on one bad morning tells you very little about how it operates over five years.
The observation with a longer life concerns autonomy and dependency together. A person whose session dies tries again or calls someone. An unattended process retries into the wall or stops without raising a hand. As more work moves onto the Salesforce platform under agent control, the number of things a sign-in failure halts grows with it, and so does the time before anyone notices.
Write the page before the next one
Nobody chooses whether their vendor has a bad morning. You choose what you already know when it arrives. Which processes stop, which ones queue, which ones fail quietly, and who tells the business what is true while the status page still says investigating.
The task this week is small. Take your three highest value Salesforce integrations and your two most autonomous automations and write one page each covering retry behaviour, token refresh on failure, what a user can still do by hand, and how the backlog drains afterwards. Run the same pass over service account identity across platforms, because the accounts nobody owns are the ones that fail without noise.
The next outage will not be the same vendor or the same component. The page you write this week still answers the only question anyone asks afterwards, which is what stopped and what it cost to catch up.
