# Salesforce's Outage Took the Support Door Down With It **Summary:** Salesforce's September 16 incident hit instances across all regions and blocked some customers from opening support cases. I would keep the recovery channel off the product's login failure path. - Canonical: https://markhuang.ai/news/salesforce-outage-took-support-with-it - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-16 - Section: News - Tags: Salesforce, Cloud Outages, Incident Response, Service Reliability, Customer Support - Source: [Salesforce Trust](https://status.salesforce.com/products/all) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A damaged cloud infrastructure hub cuts power to both enterprise workstations and an emergency support phone](https://cdn.markhuang.ai/news/salesforce-outage-took-support-with-it/hero.webp) *A recovery path is only useful if it survives the failure that sends customers looking for it.* On September 16, 2026, Salesforce's [all-products status page](https://status.salesforce.com/products/all) pointed customers to incident 20004433. The official timeline says the disruption began at 07:50 UTC and affected multiple instances across all regions. Customers saw severe delays, intermittent errors, and inaccessible services. Worse, some could not create a new support case through the Help portal. I would not let the support door depend on the login path that is failing. A status page can tell me the vendor knows about an incident. It cannot replace an independent way to report a tenant-specific emergency, share evidence, or ask for help. Any company that runs sales, service, or operational work through Salesforce has to account for that gap. The incident began as a platform problem. The blocked case form made it an incident-response design problem for customers too. ## The timeline points to a shared failure path [Salesforce's incident record](https://status.salesforce.com/incidents/20004433) shows the investigation step by step. At 08:45 UTC, Salesforce said the issue affected multiple instances across all regions and that some customers could not submit support cases. At 09:10 UTC, the company said requests were stalling while they waited for an internal login service, consuming available server resources. That update again said support case creation was affected. The working explanation then moved. Salesforce first described a possible external dependency failure involving a legacy login server and said it was considering blocking an API endpoint. Minutes later, it said a core system component had experienced increased load and lost request-processing capacity. That is not a contradiction I would try to resolve from outside. It is a live investigation changing as engineers collect evidence. By 10:56 UTC, Salesforce said it had validated a fix on a test instance and was rolling it out across the affected fleet. At 11:19 UTC, it reported that customers were starting to see service return while engineers worked on a permanent code-level fix. The recovery process was clear. The product question it left behind was harder: why did the route for asking for help become collateral damage? ## Status is not the same as support Salesforce tells customers to use Trust Status to check an instance, review incidents, see maintenance, and subscribe to notifications. Its [Trust Status documentation](https://help.salesforce.com/s/articleView?id=sf.trust_status_overview.htm\&language=en_US\&type=5) describes near-real-time email and SMS alerts. The status API also exposes incidents, maintenance, products, services, and instance status. That is a substantial public surface, and the September 16 timeline was more informative than a generic red light. A status feed answers a different question from a support channel. It can say that a broad incident exists. It cannot know whether my tenant has a separate failure, whether a queue needs to be preserved, or whether my workaround is making the damage worse. I still need a path to provide that context without authenticating through the unhealthy component. Salesforce's current [support guide](https://help.salesforce.com/s/articleView?id=001116973\&language=en_US\&type=1) recommends phone support for urgent severity-one issues. That is the fallback I would put in the runbook, along with the relevant phone number, organization identifiers, support-plan details, and named escalation contacts. I would store them outside Salesforce. Looking them up after the login path breaks is too late. > **Info:** > > My outage rule: monitoring, incident updates, and emergency support should remain reachable without the production login that may be failing. Keep the contact details and tenant identifiers in an independent runbook. ## A green tile is only one signal The all-products page is attractive because it compresses a sprawling service into one place. That compression also removes context. A product can look healthy while one region, instance, integration, or customer journey is failing. During an emerging incident, the vendor must first detect the pattern, investigate it, and decide what scope it can defend publicly. The [public Salesforce administrator discussion](https://www.reddit.com/r/salesforce/comments/1whr912/salesforce_down_for_maintenance/) is useful here, with limits. People reported intermittent access from several regions and complained that they could not file a case. Those comments do not establish the root cause or total scope. They do show what the official dashboard cannot capture well: scattered customer symptoms before everyone agrees they belong to one incident. For me, the vendor page confirms a failure that customer-side monitoring should already be able to see. Synthetic login checks, API error rates, integration queue depth, and authentication failures can show that a business process is sick before a broad status entry appears. I drew a similar conclusion from [a Claude service incident](/news/claude-outage-dependency-test). Once a cloud tool sits in the working path, its failure needs an owner and a response plan. A browser tab that someone remembers to refresh is too flimsy. ## Personalized status helps, but independence matters more Salesforce is already moving toward more specific visibility. Its [My Trust Center announcement](https://admin.salesforce.com/blog/2026/introducing-my-trust-center) says the public site reports at a generic instance level, while the newer service provides status and maintenance information tailored to a customer's tenants. Salesforce also says customers with automation tied to the legacy Trust APIs will get time to redirect those calls before the public status page is retired. That should reduce alert noise and make the incident view more relevant. It does not automatically solve the shared-dependency problem. Personalized status that requires the same identity system as the affected service can be less reachable at the moment it matters most. What matters is whether the communication and escalation paths fail independently. Salesforce can fairly argue that the public incident page did its job. It acknowledged the broad scope, recorded the changing diagnosis, and described the fleetwide rollout. I agree. My criticism is narrower: a good status page should be paired with an out-of-band way to reach support, especially when the incident itself can block case creation. ## What I would change before the next outage I would test the emergency path as a real system. Can the on-call person find the tenant ID without Salesforce? Can they reach the correct phone route for their support plan? Do they receive status updates through a channel outside the product? Can they distinguish a vendor-wide event from a local configuration problem using their own telemetry? I would also decide in advance what stops when login becomes intermittent. Automations may retry and create a backlog. Sales and support teams may start recording work elsewhere. Integrations may recover later and replay old events. The runbook needs owners for those queues and a reconciliation step after service returns. Salesforce was restoring service through a tested fleetwide rollout when I checked the incident at 11:19 UTC. I will still use its status page. I just do not want the page, the support channel, and the product all asking the same troubled login service for permission to help me recover.