A Salesforce outage on September 16 caused severe delays, intermittent errors and failures to access core services across many instances. Salesforce’s public incident updates traced stalled requests to an internal login service and later described a core component under increased load. Independent current-event reporting and status aggregation confirmed broad login and availability problems.

What the Salesforce outage affected

Salesforce classified the event as a core-service disruption. Its status updates said requests were stalling while waiting for an internal login-service response, consuming available resources. Customers reported severe delays, intermittent errors and an inability to reach some services. Salesforce also acknowledged that support-case creation was affected, removing a normal escalation route during the incident.

Independent reports described inaccessible services, errors and login trouble during the same incident window. Status aggregation also showed connected vendors reporting delayed synchronisation from Salesforce. That wider pattern matters because a CRM often sits in the middle of revenue, service and reporting processes even when employees do not interact with its interface directly.

The Salesforce outage was a dependency incident

Everyone else is reporting downtime; we are explaining the dependency chain. An identity bottleneck can stop users from opening the application, block API calls, delay data movement and prevent teams from filing support cases. A dashboard turning green does not prove that every queued update, webhook and downstream record has reconciled.

The Salesforce outage shows why CRM resilience must extend beyond availability: organisations need a way to identify missing transactions, replay safe work and verify that connected systems converge after access returns. Without that step, a short outage can leave a longer tail of stale forecasts, incomplete cases and duplicated actions.

Public disclosure September 16, 2026
Service Salesforce Core Service
Observed symptoms Login failures, delays, errors and inaccessible services
Company diagnosis Requests stalled on an internal login service; core component load increased
Secondary effect Support-case creation and connected integrations were affected
Salesforce incident chainA login-service bottleneck propagates into applications, integrations and business queues.Identitylogin requestCorecapacity stallsAppserrors + delayRecoveryreconcile work
Recovery includes checking downstream queues, not only restoring the login page.

What administrators should do after recovery

Record the incident window and list critical jobs that depend on Salesforce authentication or APIs. Check integration queues for retries and failures, compare counts across source and destination systems, and avoid blindly replaying transactions that may already have completed. Sales and service teams should identify records edited offline and assign one owner for reconciliation.

Our report on Salesforce AIforce explains how more interfaces can depend on the same governed CRM layer. The AWS Bahrain resilience case offers a related lesson: recovery claims need evidence at the data and workflow layers, not only an infrastructure status change.

What the evidence does not show

The available updates do not establish a cyberattack, data loss or a connection to Salesforce’s Dreamforce product announcements. The timing is notable but not causal evidence. Claims should remain limited to the service effects and diagnostic statements Salesforce published. Organisations need their own logs to determine whether a specific integration lost, duplicated or delayed data.

FAQs

Was Salesforce down globally?

Many instances and users across multiple countries reported disruption. The safest description is a broad core-service incident rather than a claim that every Salesforce product failed everywhere.

What caused the Salesforce outage?

Salesforce said requests stalled while waiting on an internal login service and later described increased load on a core component. A final root-cause report was not yet public at package time.

What should companies verify?

They should check authentication, integration queues, webhooks, scheduled jobs, support cases and any offline work that must be reconciled.

Sources

Salesforce Trust; Mirage News; StatusGator.

Get the day’s top stories in your inbox

One concise email. No spam, unsubscribe anytime.