On the morning of 16 September 2026, Salesforce stopped working. Not in one region, not for one tier of customer, but across hundreds of instances spanning the United States, Japan, India, the United Kingdom, France and Germany, with reports arriving from Australia, Brazil, Canada, Italy, Singapore, South Korea, Sweden and Switzerland. The disruption opened at roughly 07:50 UTC and was not marked resolved until early evening. Call it eleven hours. It was day one of Dreamforce, with 40,000 people in the room.
The interesting part is not that a large cloud platform had a bad day. It is what failed. Salesforce did not lose a data centre, a region or a disk. It lost the ability to let people log in.
TL;DR
- Salesforce’s 16 September 2026 outage lasted roughly eleven hours and hit instances in every region. The stated cause was requests stalling on an internal login service, which then consumed available server resources.
- Regional redundancy does not protect you from a shared control plane. Authentication is almost never drawn on the architecture diagram your vendor shows you.
- Customers could not raise support cases during the incident, because the support portal sat inside the failure domain.
- Recovery was not the end. Scheduled jobs did not run for some customers after service returned, and reconciliation is the expensive part.
- The deliverable nobody ships a template of is a degraded-mode runbook per critical SaaS: what the team does by hand, where data queues, who reconciles what, rehearsed once a year.
What actually happened
Salesforce’s own early description on its Trust site was that requests were stalling while waiting for a response from an internal login service, which was subsequently consuming available server resources. A later update attributed it to an external dependency failure affecting a legacy login server, with core system components experiencing increased load that limited their capacity to process requests.
The remediation path is worth reading closely, because it tells you how long these things take even when a very capable team is on it. Instance restarts were tried and abandoned as an approach. A fix was tested on a single instance and validated a little over two hours in, then rolled out fleetwide in phases, with manual restarts where the automated fix did not complete. Hyperforce environments were among the last to come back.
No attack, no breach, no lost data. An old login component buckled under load and took the front door off its hinges.
Regional redundancy does not cover a shared control plane
Every enterprise SaaS sales deck contains a map. Regions, availability zones, replication arrows, a figure with a lot of nines in it. That map describes the data plane: where your records live and how many copies exist. It is usually accurate, and on 16 September it was also irrelevant, because every one of those regions called the same identity service.
This is the distinction that matters and the one that almost never appears in a vendor assessment. The data plane is the part that serves your requests. The control plane is the part that decides whether you are allowed to make them: authentication, session issuance, entitlement checks, tenant routing, provisioning. Control planes are centralised on purpose, because consistency of identity is the whole point of single sign-on. The consequence is that a control plane is a shared failure domain by design, and replicating the data plane across twelve regions does nothing to widen it.
As one analyst put it after the incident, cloud does not eliminate architectural dependencies, it sometimes makes them less visible. That is the honest version. The dependency was always there. It was simply not on any diagram you were shown.
The practical question for a CTO is therefore not “how many regions does this vendor run in” but “which components are global, and what happens to me when one of them is unavailable”. Ask it in procurement, in writing. Most vendors will answer it. Very few are asked. We made the same argument about DNS resolution and about payment providers as a single point of failure: the shape repeats because the shape is structural.
Your escalation path was inside the failure domain
During the outage, some customers could not submit new support cases. The portal for reporting that you cannot log in required you to log in.
This is not a Salesforce peculiarity. It is the default configuration of most stacks. Your status dashboard is hosted by a vendor whose auth you use. Your incident channel is a SaaS product. Your runbooks are in a wiki behind SSO.
A status page is also an estimate produced by people working with partial telemetry during a live incident, not a measurement. If your plan begins with “check the status page and raise a ticket”, it has two dependencies on the thing that is broken.
The fix is unglamorous and takes an afternoon: one out-of-band channel that shares no identity provider, no hosting and no vendor with your primary stack, with the numbers and the runbook available offline. Test it by trying to run a fifteen-minute incident call without touching your main suite.
Recovery is when the expensive work starts
The detail most coverage skipped: after service was restored, some customers found that scheduled jobs had not run as expected. Batch jobs, syncs and automations that were supposed to fire during those eleven hours simply did not, and the platform coming back did not replay them.
This is where the real money goes. The invoices that never issued. The leads that never synced to the CRM from the form that kept accepting submissions. The webhooks that fired into a 503 and were never retried because the sender’s retry budget expired in four hours, not eleven. The nightly reconciliation that ran against a half-populated dataset and produced a clean-looking report.
An outage of this shape leaves behind a data integrity problem, not just a lost morning. Two questions decide how bad yours is. First, do your integrations queue or drop when the far end is unavailable? A queue with a dead-letter destination turns an outage into a delay. A fire-and-forget HTTP call turns it into silent data loss. Second, can you enumerate what should have happened in a given window and diff it against what did? If the answer involves someone scrolling through logs, budget days rather than hours.
The deliverable: a degraded-mode runbook per critical SaaS
Business continuity documents tend to be written for the building burning down. Almost nobody writes the far more likely one, which is that a vendor you do not control is unavailable for a working day and you still have customers. Under NIS2, business continuity and crisis management are explicit obligations rather than good practice, and the same logic applies whether or not you are in scope: you are expected to have thought about this before it happens. We covered how those obligations arrive through contracts rather than legislation earlier this month.
A degraded-mode runbook is one page per critical vendor and answers five things.
- What the team does by hand for the first hour. Named tasks, not principles. If sales cannot open the CRM, where do call notes go so that they are recoverable later?
- Where inbound data queues. Forms, webhooks and integrations should write to something you own before they write to the vendor. This is a small architectural decision made in advance and an impossible one made at 09:00 on the day.
- What you tell customers, and who says it. Drafted in advance, approved in advance, publishable from infrastructure that is not affected.
- Who reconciles what on the way back. Name the person and the dataset. Recovery is a checklist, not an announcement.
- When you last rehearsed it. Once a year, in office hours, with the vendor’s login deliberately blocked at the network level. Anything you have not rehearsed is a hypothesis.
Then do the arithmetic that makes the case to the board. Most SaaS agreements credit a percentage of one month’s fee against an availability miss. For an eleven-hour outage on a typical enterprise contract, that credit is a rounding error against the cost of a sales floor standing still and a week of reconciliation afterwards. The SLA is not insurance. It is a statement of how little the vendor owes you when the risk lands, which is precisely why the mitigation has to be yours.
Build the queue before you need it
None of this argues against cloud platforms, and the alternative is not self-hosting your CRM. It argues for knowing which parts of your stack are global, where your data waits when they are unavailable, and who puts it right afterwards.
REPTILEHAUS builds the unglamorous half of that: integration layers that queue rather than drop, reconciliation tooling that can tell you what a missing window contains, and architecture reviews that go looking for the shared control planes nobody drew. If your last outage post-mortem ended with “the vendor fixed it”, get in touch and we will help you write the half that is yours.
📷 Photo by Abi abdullah miyad on Unsplash
