Salesforce outages in 2025 did not follow one simple pattern. Some incidents were confined to particular instances or products, while others crossed multiple clouds or depended on third-party infrastructure. For operations, IT, CRM, commerce, and marketing teams, the useful retrospective is not a list of every Trust post published that year. It is a review of the disruptions that expose recurring failure modes: authentication dependencies, data-center infrastructure, database recovery, content-delivery networks, cloud-provider DNS, and changes that need to be rolled back.
This reference focuses on a selected set of significant 2025 incidents documented by Salesforce Trust. “Major” here means operationally notable because of duration, breadth, or the type of customer workflow affected; it does not mean every customer was affected, and it is not a complete incident census. Exact impact depended on product, instance, region, and tenant.
| Date | What Salesforce reported | Reported duration or recovery window | Why it matters operationally |
|---|---|---|---|
| February 7 | Service disruption for a subset of customers, with Salesforce citing resource constraints associated with high network traffic utilization. | 2 hours 20 minutes | Capacity and traffic pressure can turn performance degradation into outright unavailability. |
| February 13–14 | Service disruption linked to a third-party vendor issue; Salesforce said the vendor found damage to physical network infrastructure while Salesforce worked on failover. | 1 hour 45 minutes | External connectivity can become part of the effective Salesforce availability boundary. |
| June 10–11 | A multi-cloud event affected authentication and services across products including Heroku, Commerce, Marketing Cloud, and other Salesforce services. | One Trust incident ran 22 hours 43 minutes | Identity and shared platform dependencies can create broad business impact even when individual applications remain healthy. |
| June 18–19 | A cooling-system failure at the Indianapolis data center triggered a network disruption; Salesforce reported that most servers in the more severely affected stacks went offline before staged restoration. | Service disruption phase reported as 18 hours 44 minutes on the cited incident | Physical facilities, power, networking, virtual infrastructure, databases, and application recovery can form a long dependency chain. |
| October 2–6 | Marketing Cloud customers on database DB10016 lost service because the database was unavailable; Salesforce worked through database restore and validation. | Service disruption phase reported as 3 days 16 hours before moving to performance degradation | Database recovery can be much slower than application restart, so continuity plans need a long-duration mode. |
| October 20 | Multiple Salesforce clouds were affected by a DNS issue at a third-party cloud infrastructure vendor. Commerce Cloud, MuleSoft, Marketing Cloud Account Engagement, Heroku, and other services reported related impact. | Varied by service; cited Commerce disruption was 3 hours 19 minutes, while a MuleSoft incident remained open for 16 hours 23 minutes | A single provider-level dependency can create different symptoms and recovery times across products. |
| November 18 | A subset of Commerce Cloud storefronts experienced intermittent HTTP 500 errors. Salesforce said its platform and network were operating normally and attributed the disruption to a third-party CDN provider configuration update that was rolled back. | 4 hours 40 minutes | Customer-facing availability can fail at the delivery edge even when the core application platform is healthy. |
Source records: Salesforce Trust incident 13702, Salesforce Trust incident 13729, Salesforce Trust incident 10014307, Salesforce Trust incident 10014353, Salesforce Trust incident 20003296, Salesforce Trust Commerce Cloud incident 20003368, Salesforce Trust MuleSoft incident 20003364, and Salesforce Trust Commerce Cloud incident 20003465.
Salesforce Trust reports incidents by product, instance, service, and sometimes by database or regional component. The February 7 disruption affected a subset of customers. The October 2 Marketing Cloud incident centered on one database. The October 20 event spanned multiple clouds but produced different recovery times and symptoms. For responders, the first useful question is therefore not simply whether Salesforce is down, but which tenant, product, region, instance, and dependency is failing.
Salesforce provides a way to find an organization’s status using its My Domain name. The official support article explains how to use the Trust status page to locate instance-specific status and maintenance information: Salesforce Help: get org status and maintenance dates with My Domain.
Several 2025 incidents show why SaaS continuity planning cannot stop at the SaaS vendor boundary. The February 13–14 incident involved a third-party network vendor. The October 20 multi-cloud disruption was tied to a DNS issue at a third-party cloud infrastructure vendor. On November 18, Salesforce reported Commerce Cloud storefront connectivity problems associated with a third-party CDN provider configuration update.
The lesson is not that third parties are inherently unreliable. It is that customer workflows depend on a chain of services: identity, DNS, networking, content delivery, cloud infrastructure, APIs, and application services. Your incident model should follow that chain.
The June 18–19 data-center event is a strong example. Salesforce described restoring physical and virtual resources, then bringing databases and replicas online, validating data parameters, and recovering dependent services. The October Marketing Cloud database disruption likewise moved through restore, configuration checks, validation, and then a later performance-degradation phase.
That distinction matters for business teams. “The platform is recovering” does not necessarily mean every queue is drained, every integration has replayed, every storefront is stable, or every scheduled job ran successfully.
A useful Trust review has three passes. First, read the impacted services and instances. Second, compare the published start time with your telemetry; Salesforce sometimes revises incident start times as investigations improve. Third, distinguish service disruption from performance degradation or feature disruption. Those labels describe different operational states, and a feature-level incident may leave most of the platform usable.
Do not assume that an incident duration equals the period during which every affected customer experienced identical symptoms. Salesforce updates often describe expanding or shrinking impact radius, staged recovery, or product-specific restoration. For internal reporting, record both the vendor’s official timeline and your own observed impact window.
The strongest resilience lesson from 2025 is that an outage plan should have more than a 30-minute mode. A brief disruption may only require communication and patience. A multi-hour event requires queued work and controlled manual processes. A disruption lasting into multiple days, such as the cited Marketing Cloud database incident, demands staffing handoffs, backlog management, customer communication, and a recovery plan for deferred campaigns, imports, exports, API operations, and reporting.
Define recovery priorities before an outage. For a sales organization, lead intake and customer commitments may come before analytics refreshes. For a retailer, order capture, inventory accuracy, and customer-service visibility may be the critical path. For a marketing team, the priority may be preventing duplicate sends and preserving campaign state rather than trying to force every scheduled activity through an unstable system.
Use the retrospective to test assumptions, not to predict the next failure. The 2025 incidents show that the initiating problem can come from traffic pressure, vendor networking, physical cooling, databases, DNS, CDN configuration, or software changes. No single workaround covers all of those.
A mature Salesforce continuity plan should therefore map business processes to technical dependencies, assign fallback owners, define safe retry behavior, keep Salesforce Trust monitoring close to the incident workflow, and include a formal reconciliation phase after service recovery. The most useful metric is not simply “time until Salesforce turned green.” It is time until the business process was verified end to end and the backlog was safely cleared.
This retrospective was prepared from Salesforce’s own Trust and Help records and focuses on selected incidents from calendar year 2025. Salesforce published many other incident notices during the year, including shorter and more narrowly scoped events. Some Trust pages were updated after the initial event as impact windows and affected components were clarified. For current service health, use Salesforce Trust Status rather than relying on a historical article.
Review notable Salesforce outages in 2025, what failed, how long selected incidents lasted, and the practical resilience lessons teams can apply.
Build a practical Salesforce downtime continuity plan with impact analysis, RTO/RPO targets, manual workarounds, integration controls, and recovery checks.
Learn how to contact Salesforce Support during a major outage: check Trust Status, choose the right channel, open a strong case, and track recovery.
Troubleshoot Salesforce Workbench login, REST Explorer, timeout, 503, API-version, and limit errors during downtime with a practical diagnostic checklist.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Understand the main causes of widespread cloud downtime, how failures cascade, what to check first, and how to design a more resilient recovery plan.
If Datorama or Marketing Cloud Intelligence seems down, use this evidence-based checklist to verify the outage, protect reporting quality, and know when data is trustworthy again.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Understand how Salesforce and AWS connect through Hyperforce, integrations, networking, data residency, outages, and shared operational responsibilities.
An AWS outage does not automatically mean Salesforce is down. Learn how Hyperforce, regions, instances, and Salesforce Trust determine whether your org is affected.
