SAN FRANCISCO, Sept. 16, 2026 - Salesforce spent several hours on Wednesday recovering from a broad service incident that left customers in multiple regions facing slow requests, intermittent errors and difficulty reaching parts of the platform.
The outage was significant not because one isolated application stopped responding, but because the failure sat close to a shared part of the platform: the path used to process customer requests and authentication-related traffic.
Salesforce’s Trust updates described requests becoming stuck while waiting on an internal login service. Those stalled requests consumed available server resources. The company later said increased load on a core system component had reduced its ability to process customer requests.
By the afternoon in India, engineers had identified a mitigation, tested it, and begun deploying the fix across the affected fleet. Customers then started to see services recover progressively rather than all at once.
As of this article’s 6:19 p.m. IST cutoff on September 16, the most important point is that Salesforce had described the operational failure mode and was rolling out remediation, but it had not yet published a final root-cause analysis establishing the original technical trigger.
That distinction matters.
“Requests stalled behind an internal login service” explains how the outage propagated.
It does not yet answer the deeper question of why that service or the component around it entered the failure state in the first place.
The outage timeline
Salesforce’s public Trust system is designed to provide incident information while an outage is still unfolding. Salesforce says its objective is to post critical customer-impacting incidents within 10 minutes of becoming aware of them and then provide updates at least every 30 minutes, or sooner when significant information becomes available.
The September 16 incident developed quickly.
Around 8:30 UTC, roughly 2:00 p.m. IST
Salesforce acknowledged a broad service problem affecting multiple instances.
Customers were experiencing severe delays, intermittent errors and problems reaching some services.
This was already more serious than a cosmetic user-interface issue.
A degraded request path can affect sign-in, page loading, API calls, automated processes and workflows that depend on successful communication with the Core platform.
The company also indicated that support case creation was affected for some customers.
That is operationally important because an outage that also interferes with the normal support channel makes incident communication harder at exactly the time customers need it most.
Early investigation: requests waiting on login
Salesforce then reported that customer requests were stalling while waiting for a response from an internal login service.
The requests did not simply fail and disappear.
They remained in the system long enough to consume available server resources.
This is a classic cascade pattern in distributed software.
A downstream dependency becomes slow.
Upstream services continue accepting work.
Requests accumulate.
Threads, connections, memory, queues or other finite resources become occupied.
As those resources approach exhaustion, requests that have nothing directly wrong with them can also begin slowing or timing out.
At that point, the visible problem becomes much larger than the original bottleneck.
Restart and mitigation work
During the incident, Salesforce explored restoration paths, including controlled restart activity and changes intended to remove the bottleneck.
A restart can be useful when a process has entered a bad state or resources cannot be recovered cleanly.
But restarts do not solve an underlying software or dependency problem if new traffic immediately recreates the same conditions.
The important signal in Salesforce’s later updates was that the incident response moved toward a specific fix rather than relying only on restarts.
10:42 UTC, 4:12 p.m. IST
Salesforce provided a more direct description of the platform-level problem.
It said increased load on a core system component had reduced its ability to process customer requests.
This fits the earlier observation that requests were accumulating while waiting on an internal login service.
The two statements are not contradictory.
One describes where requests were waiting.
The other describes the consequence: reduced processing capacity in a shared component.
Testing before fleetwide deployment
Salesforce then tested its proposed fix before expanding deployment.
That staging is important in a platform serving thousands of customer instances.
A rushed global change can turn one outage into another.
The safer pattern is to validate a fix on a controlled subset, observe whether request latency, error rates and resource pressure normalize, and then expand the deployment.
11:27 UTC, 4:57 p.m. IST
Salesforce said the fix was being rolled out across the affected fleet and that customers were beginning to see services return toward normal.
Recovery was progressive.
That is expected in a distributed cloud platform.
Different instances can receive the fix at different times.
Existing backlogs may also need to drain after the underlying bottleneck has been removed.
A customer can therefore experience partial recovery before every service metric has fully normalized.
What was actually affected
The safest description is broad Core-service and access degradation across affected Salesforce instances.
The visible effects included severe latency, intermittent errors and difficulty accessing services.
Authentication was central to the incident investigation because requests were observed waiting on an internal login service.
Support case creation was also affected for some customers.
The impact of a Core-platform incident varies by organization.
A company using Salesforce only for a small internal workflow may experience inconvenience.
A company using it as the system of record for sales, customer support, field operations, case management, approvals or API-driven integrations can experience an operational interruption.
That is why the same incident can have very different business effects from one customer to another.
Why a login bottleneck can affect much more than logging in
It is easy to interpret “login service” as meaning only the screen where a user enters a password.
Enterprise authentication is much broader.
Cloud applications continuously validate sessions, issue or refresh tokens, authorize API access, route users to the correct organization and enforce identity rules.
Machine-to-machine integrations also depend on authentication.
An application might authenticate once and then make thousands of API calls.
A mobile client may renew credentials in the background.
An integration job may obtain a token before processing records.
If a shared identity or request-processing dependency slows down, the result can therefore appear across many workflows even when users are not manually signing in at that moment.
This helps explain why a problem described initially around login behavior can manifest as generalized delays and errors.
Resource exhaustion is the mechanism that turns a bottleneck into an outage
The technical phrase “using up available server resources” is one of the most important details Salesforce disclosed.
Cloud services are designed to handle enormous load, but every layer still has finite capacity.
There are finite worker processes.
Finite network connections.
Finite database connections.
Finite request queues.
Finite memory.
Finite CPU.
Normally, requests complete quickly enough that those resources are released and reused.
A stalled dependency changes the equation.
Imagine a service capable of processing 100,000 concurrent requests.
If each request usually finishes in 100 milliseconds, capacity turns over rapidly.
If a dependency suddenly makes a large portion of those requests wait for tens of seconds, the same amount of infrastructure can become saturated even if incoming traffic has not increased dramatically.
New work then joins a growing queue.
Latency rises.
Clients retry.
Retries create additional load.
The system can enter a feedback loop.
This is why distributed systems use timeouts, circuit breakers, rate limits, load shedding and backpressure.
The final Salesforce root-cause analysis will need to explain which protection failed or proved insufficient in this incident.
What Salesforce has not yet established publicly
At the cutoff for this article, Salesforce had not published a final technical root cause.
That means several tempting explanations should not be presented as fact.
There is no verified basis to say the outage was caused by a cyberattack.
There is no official evidence that an AI workload triggered it.
There is no confirmed public evidence that the company’s broader Hyperforce migration caused the incident.
And there is no basis to attribute the outage to the separate Chrome and Microsoft Edge 153 freezing issue that Salesforce has been tracking since early September.
That browser problem is a different incident.
Salesforce says the Chrome and Edge 153 freezing behavior was triggered by an external browser update and is not a Salesforce code issue.
The September 16 outage, by contrast, involved shared platform request processing and an internal login dependency.
Conflating the two would produce the wrong diagnosis.
The Hyperforce login migration is relevant context, not a confirmed cause
Salesforce has been changing the architecture of some global login endpoints during 2026.
The company has been migrating endpoints such as login.salesforce.com from Salesforce-managed first-party data centers toward Hyperforce infrastructure.
It has advised certain customers using private network paths and IP allowlists to adopt My Domain and update connectivity configurations.
That migration is important context because identity and routing infrastructure is changing.
But context is not causation.
Unless Salesforce’s final incident analysis links the September 16 outage to that work, the two should remain separate.
A high-quality outage report must resist the temptation to turn chronological proximity into technical proof.
Why recovery takes time even after a fix is found
A status page saying “fix is being rolled out” does not mean every user becomes healthy at the same second.
Fleetwide deployment has several stages.
First, the code or configuration must reach affected infrastructure.
Second, services may restart or reload.
Third, health checks must confirm they are functioning.
Fourth, queues created during the outage need to drain.
Fifth, dependent integrations need to reconnect.
Sixth, clients that cached errors or exhausted their own connection pools may need to recover.
This creates a recovery curve rather than a recovery switch.
Some customers can see normal performance while others are still affected.
The same customer can also see the web interface recover before a background integration or automated queue has fully caught up.
What companies should check after Salesforce says services are healthy
Restoration is not the end of incident response for customers.
Organizations that rely heavily on Salesforce should validate their own workflows.
The first check is authentication.
Admins should confirm that interactive logins, single sign-on and connected applications are authenticating normally.
The second is API traffic.
Integration teams should examine failed calls, timeout spikes and retry queues.
A retry mechanism can protect an integration during an outage, but it can also create duplicates if the original request succeeded and the client never received the response.
The third check is automation.
Scheduled jobs, Flow executions, asynchronous Apex, platform events and external workflow systems should be inspected for backlogs or failed runs where relevant.
The fourth is customer support.
If cases could not be created during part of the outage, businesses should verify whether requests arrived through alternate channels and whether any need to be entered manually.
The fifth is downstream reconciliation.
Any process that moved orders, leads, customer updates, billing records or support events between Salesforce and another system should be checked for missing or duplicate records.
The objective is not simply to prove that Salesforce is reachable again.
It is to prove that the business process is complete.
The effect on Salesforce itself
The direct financial effect of the incident is not publicly known.
Salesforce has not disclosed an outage-related revenue loss, customer compensation figure or material financial impact.
It would therefore be irresponsible to invent one.
The reputational effect is easier to understand.
Salesforce sells software that many organizations treat as operational infrastructure.
Reliability is part of the product.
In its first quarter of fiscal 2027, Salesforce reported $11.1 billion in revenue and said its Core products processed nearly one trillion API calls during the quarter.
Those numbers do not tell us how many requests were affected on September 16.
They show the scale at which Salesforce operates and why even a few hours of degraded Core service can matter to customers.
The timing is also notable.
Dreamforce 2026 is running in San Francisco from September 15 through September 17.
The company is using the event to present its strategy for the “Agentic Enterprise,” with AI agents increasingly connected to business data and workflows.
A Core-platform outage during the same week creates an uncomfortable but useful reminder: advanced AI systems still depend on conventional infrastructure such as authentication, request routing, capacity management and resilient distributed services.
Why an AI-era Salesforce outage matters more, not less
Enterprise software is becoming more automated.
That increases the cost of downtime.
When a human salesperson cannot load a CRM record, one employee is delayed.
When hundreds of automated agents, integrations and workflows depend on the same platform, a failure can interrupt machine-driven work at much larger scale.
Salesforce itself says Agentforce and Data 360 ARR had reached nearly $3.4 billion in the first quarter of fiscal 2027, while the company had processed 3.8 billion Agentic Work Units to date at that point.
As automation expands, resilience has to expand with it.
An AI agent cannot work around an unavailable authentication path unless the architecture has been designed for that failure.
This makes identity infrastructure, graceful degradation and cross-service isolation increasingly strategic.
Why multiple data centers do not prevent every outage
Salesforce says its infrastructure is designed to avoid single points of failure.
First-party instances use geographically separated active and ready sites.
Hyperforce runs across multiple availability zones with active application infrastructure.
That protects against many hardware and data-center failures.
But geographic redundancy does not automatically solve logical failures.
If the same software defect, dependency bottleneck or configuration problem is present across multiple sites, redundant infrastructure can reproduce the same failure in multiple places.
This is the difference between hardware redundancy and failure-domain isolation.
A platform can have healthy servers in several data centers while a shared authentication or control dependency still degrades the service.
The final post-incident report should make clear which failure domain was involved and why infrastructure redundancy did not contain the blast radius.
What a complete root-cause report should answer
Salesforce’s final analysis should ideally answer at least seven technical questions.
First, what was the initial trigger?
Was it a software change, configuration change, traffic pattern, dependency behavior or another event?
Second, which component first became unhealthy?
The public updates identified an internal login service and a core component under increased load, but the causal order still needs to be documented.
Third, why did requests wait instead of failing fast?
This is central to understanding resource exhaustion.
Fourth, why did normal capacity protections not contain the incident?
Fifth, why did the impact spread across multiple instances or regions?
Sixth, what specific fix was deployed?
And seventh, what permanent controls will prevent recurrence?
The difference between a strong incident report and a weak one is not the apology.
It is whether customers can understand the chain of failure and the engineering change that breaks that chain.
What Salesforce’s immediate solution appears to have done
The recovery pattern suggests the deployed fix reduced or removed the condition that was preventing the core component from processing requests normally.
Salesforce first tested the remediation before broad deployment.
It then moved to fleetwide rollout.
Customers began seeing service restoration as that deployment progressed.
That is the correct operational sequence for a high-risk production fix.
Identify the failure mode.
Develop a mitigation.
Validate it in a controlled environment.
Expand gradually.
Monitor request latency, errors and resource use.
Continue until the fleet is stable.
The remaining work is to determine whether the deployed mitigation is the permanent solution or whether further architectural changes are required.
The next 24 hours matter
After a major outage, engineering teams typically move from emergency restoration into stabilization and investigation.
The first priority is making sure the fix holds.
Teams monitor latency, error rates, authentication success, CPU and memory pressure, queue depth and dependency health.
The second priority is clearing residual backlog.
The third is confirming that no secondary problems were introduced during recovery.
The fourth is reconstructing the timeline from logs, metrics and changes.
Customers should therefore expect status communications to become less frequent after stability returns, followed later by a more complete explanation.
A permanent root-cause analysis may take longer than service restoration because engineers need evidence strong enough to separate the initial trigger from downstream symptoms.
What customers can do to reduce dependency risk
No enterprise can eliminate dependence on a cloud platform it actively uses.
It can reduce the business damage from an outage.
Critical integrations should use idempotency so retries do not create duplicates.
API clients should use exponential backoff rather than aggressive retry loops.
Applications should have sensible timeouts.
Operational teams should know which workflows can continue manually.
Customer-support organizations should have an alternate intake channel if their primary case system is unavailable.
Executives should understand which business functions stop when Salesforce authentication or Core Service is degraded.
Companies should also subscribe directly to Trust notifications for their instances instead of discovering incidents through social media.
Salesforce says Trust provides instance-level incident histories and near-real-time notifications.
That is the authoritative channel customers should monitor.
The larger lesson from September 16
The outage is a reminder that the most consequential failures in enterprise software are often not the most visually dramatic ones.
A data center did not need to burn down.
A global network did not need to disappear.
A shared internal dependency becoming slow was enough to create a broad capacity problem.
Modern cloud systems are built from layers of services that depend on one another.
Resilience therefore depends on more than having spare servers.
It depends on making sure one slow dependency cannot consume the resources of everything waiting behind it.
This is the engineering challenge behind timeouts, bulkheads, circuit breakers, isolation and backpressure.
The September 16 incident will ultimately be judged by how Salesforce changes those protections after the final cause is known.
What users should expect next
The immediate expectation is continued stabilization as the fleetwide fix completes and residual workload clears.
Customers on affected instances should see latency and error rates return toward normal as their infrastructure receives the remediation.
The next official milestone should be confirmation that the incident is fully resolved.
After that, the more important document will be the technical follow-up explaining the trigger and preventive action.
Until Salesforce publishes that final analysis, the responsible conclusion is narrower.
The company identified a condition in which customer requests stalled behind an internal login dependency.
That behavior consumed server resources.
A core component then lacked enough capacity to process requests normally.
Salesforce developed and tested a fix.
It began deploying that fix across the affected fleet.
And customers started recovering.
Everything beyond that, including the original trigger, remains subject to the company’s final investigation.
The strict conclusion
The September 16 Salesforce outage was not simply a login-screen problem.
It was a distributed-systems capacity incident in which a shared authentication-related dependency became part of a chain that slowed or blocked customer requests and consumed finite platform resources.
That is why users experienced a mixture of access problems, severe delays and intermittent errors rather than one clean failure mode.
Salesforce’s response moved from investigation and restart attempts toward a tested fleetwide fix, with recovery becoming visible by late afternoon in India.
For Salesforce, the incident lands at a sensitive moment.
The company is positioning its platform as the operating layer for increasingly automated, AI-driven enterprise work.
That raises the standard for Core reliability rather than lowering it.
For customers, the lesson is equally direct.
Cloud platforms can be highly redundant and still experience logical failures in shared services.
The correct response is not to assume those failures will never happen.
It is to build integrations, support processes and business-continuity plans that remain controlled when they do.
The platform was recovering by the time of publication.
The final technical story, however, will not be complete until Salesforce publishes the root cause, the exact trigger and the engineering changes intended to prevent a repeat.
Reader questions
Frequently asked questions
What caused the Salesforce outage on September 16, 2026?
Salesforce said requests were stalling while waiting for an internal login service and consuming available server resources. It later said increased load on a core system component reduced request-processing capacity. At the article cutoff, Salesforce had not yet published the final underlying root cause.
What Salesforce services were affected?
Affected Salesforce instances experienced broad Core-service degradation, including severe delays, intermittent errors and difficulty accessing services. Salesforce also said support case creation was affected for some customers.
When did Salesforce begin restoring service?
Salesforce said by around 11:27 UTC, or 4:57 p.m. IST, that its fix was being rolled out across the affected fleet and that customers were beginning to see services return.
Was the Salesforce outage caused by a cyberattack?
Salesforce had not reported evidence of a cyberattack as the cause at the time this article was published. The company described an internal login and core-component capacity problem and continued investigating the underlying trigger.
Was the September 16 outage the same as the Chrome and Edge freezing issue?
No. Salesforce separately identified the Chrome and Edge 153 freezing issue as a non-Salesforce browser-related problem triggered by an external browser update. The September 16 outage involved Core request processing and an internal login dependency.
Why can a login-service problem affect other Salesforce workflows?
Authentication services are used not only for interactive sign-in but also for sessions, tokens, API integrations and machine-to-machine access. If a shared dependency becomes slow and requests accumulate, resource exhaustion can cause broader latency and errors.
What should Salesforce customers check after service is restored?
Organizations should verify interactive and SSO logins, API integrations, failed or duplicate requests, automation queues, scheduled jobs, case creation, data synchronization and any downstream systems that may have missed or retried transactions.
Has Salesforce published a final root-cause analysis?
Not at the publication cutoff used for this article. Salesforce had explained the immediate failure mechanism and deployed a fix, but the final technical trigger and long-term preventive actions had not yet been published.
Nexuswild welcomes factual corrections. Email [email protected] with evidence and the article URL.
