Salesforces avbrott under 2025 följde inte ett enkelt mönster. Vissa incidenter var begränsade till specifika instanser eller produkter, medan andra var kopplade till flera moln eller var beroende av tredjepartsinfrastruktur. För drift-, IT-, CRM-, handels- och marknadsföringsteam är den användbara retrospektiven inte en lista över alla Trust-inlägg som publicerades det året. Det är en granskning av de störningar som avslöjar återkommande fellägen: autentiseringsberoenden, datacenterinfrastruktur, databasåterställning, innehållsleveransnätverk, molnleverantörers DNS och ändringar som måste återställas.
Denna referens fokuserar på en utvald uppsättning betydande incidenter från 2025 som dokumenterats av Salesforce Trust. ”Större” betyder här operativt anmärkningsvärd på grund av varaktighet, omfattning eller typen av kundarbetsflöde som påverkats; det betyder inte att alla kunder påverkades, och det är inte en fullständig incidenträkning. Den exakta effekten berodde på produkt, instans, region och hyresgäst.
| Datum | Vad Salesforce rapporterade | Rapporterad varaktighet eller återhämtningsfönster | Varför det är viktigt operativt |
|---|---|---|---|
| 7 februari | Tjänststörningar för en delmängd av kunderna, där Salesforce hänvisar till resursbegränsningar i samband med hög nätverkstrafikutnyttjande. | 2 timmar och 20 minuter | Kapacitet och trafiktryck kan förvandla prestandaförsämring till fullständig otillgänglighet. |
| 13–14 februari | Tjänststörningar kopplade till ett problem hos en tredjepartsleverantör; Salesforce uppgav att leverantören upptäckte skador på den fysiska nätverksinfrastrukturen medan Salesforce arbetade med redundans. | 1 timme och 45 minuter | Extern anslutning kan bli en del av den effektiva tillgänglighetsgränsen för Salesforce. |
| 10–11 juni | En händelse i flera moln påverkade autentisering och tjänster i produkter, inklusive Heroku, Commerce, Marketing Cloud och andra Salesforce-tjänster. | En Trust-incident varade i 22 timmar och 43 minuter | Identitet och delade plattformsberoenden kan skapa bred affärspåverkan även när enskilda applikationer förblir felfria. |
| 18–19 juni | Ett kylsystemfel vid datacentret i Indianapolis utlöste ett nätverksavbrott; Salesforce rapporterade att de flesta servrar i de hårdast drabbade serverplattformarna gick offline innan den etappvisa återställningen genomfördes. | Avbrottsfasen rapporterades som 18 timmar och 44 minuter för den angivna incidenten | Fysiska anläggningar, strömförsörjning, nätverk, virtuell infrastruktur, databaser och applikationsåterställning kan bilda en lång beroendekedja. |
| 2–6 oktober | Marketing Cloud-kunder på databasen DB10016 förlorade tjänsten eftersom databasen inte var tillgänglig; Salesforce arbetade sig igenom databasåterställning och validering. | Avbrottsfasen för tjänsten rapporterades som 3 dagar 16 timmar innan den övergår till prestandaförsämring | Databasåterställning kan vara mycket långsammare än omstart av applikationer, så kontinuitetsplaner behöver ett långsiktigt läge. |
| 20 oktober | Flera Salesforce-moln påverkades av ett DNS-problem hos en tredjepartsleverantör av molninfrastruktur. Commerce Cloud, MuleSoft, Marketing Cloud Account Engagement, Heroku och andra tjänster rapporterade liknande effekter. | Varierade beroende på tjänst; den nämnda handelsstörningen var 3 timmar och 19 minuter, medan en MuleSoft-incident förblev öppen i 16 timmar och 23 minuter. | Ett beroende på en enda leverantörsnivå kan skapa olika symptom och återställningstider mellan olika produkter. |
| 18 november | En delmängd av Commerce Cloud-butikerna upplevde intermittenta HTTP 500-fel. Salesforce uppgav att deras plattform och nätverk fungerade normalt och tillskrev störningen en konfigurationsuppdatering från en tredjepartsleverantör av CDN som hade rullats tillbaka. | 4 timmar och 40 minuter | Kundorienterad tillgänglighet kan misslyckas vid leveransgränsen även när kärnapplikationsplattformen är felfri. |
Källposter: 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 och Salesforce Trust Commerce Cloud-incident 20003465 .
Salesforce Trust rapporterar incidenter per produkt, instans, tjänst och ibland per databas eller regional komponent. Störningen den 7 februari påverkade en delmängd av kunderna. Marketing Cloud-incidenten den 2 oktober var centrerad mot en databas. Händelsen den 20 oktober omfattade flera moln men gav olika återställningstider och symtom. För respondenter är den första användbara frågan därför inte bara om Salesforce är nere, utan vilken hyresgäst, produkt, region, instans och beroende som inte fungerar.
Salesforce erbjuder ett sätt att hitta en organisations status med hjälp av dess Min domän-namn. Den officiella supportartikeln förklarar hur man använder sidan Förtroendestatus för att hitta instansspecifik status- och underhållsinformation: Salesforce-hjälp: få organisationsstatus och underhållsdatum med Min domän .
Flera incidenter under 2025 visar varför SaaS-kontinuitetsplanering inte kan stanna vid SaaS-leverantörens gräns. Incidenten den 13–14 februari involverade en tredjepartsleverantör av nätverk. Störningen i multimolnet den 20 oktober var kopplad till ett DNS-problem hos en tredjepartsleverantör av molninfrastruktur. Den 18 november rapporterade Salesforce problem med anslutningen till Commerce Cloud-butiken i samband med en konfigurationsuppdatering för en tredjepartsleverantör av CDN.
Lärdomen är inte att tredje part är i sig opålitliga. Den är att kundernas arbetsflöden är beroende av en kedja av tjänster: identitet, DNS, nätverk, innehållsleverans, molninfrastruktur, API:er och applikationstjänster. Din incidentmodell bör följa den kedjan.
Datacenterevenemanget den 18–19 juni är ett starkt exempel. Salesforce beskrev återställning av fysiska och virtuella resurser, onlineföring av databaser och repliker, validering av dataparametrar och återställning av beroende tjänster. Databasstörningen i Marketing Cloud i oktober gick likaledes igenom återställning, konfigurationskontroller, validering och sedan en senare prestandaförsämringsfas.
Den skillnaden är viktig för affärsteam. ”Plattformen återhämtar sig” betyder inte nödvändigtvis att alla köer är tömda, alla integrationer har spelats om, alla butiker är stabila eller att alla schemalagda jobb har körts utan problem.
En användbar förtroendegranskning har tre omgångar. Först, läs de berörda tjänsterna och instanserna. För det andra, jämför den publicerade starttiden med din telemetri; Salesforce reviderar ibland incidentstarttider allt eftersom utredningarna förbättras. För det tredje, skilj mellan tjänsteavbrott och prestandaförsämring eller funktionsavbrott. Dessa etiketter beskriver olika driftstillstånd, och en incident på funktionsnivå kan göra att större delen av plattformen är användbar.
Anta inte att en incidents varaktighet är lika med den period under vilken varje drabbad kund upplevde identiska symptom. Salesforce-uppdateringar beskriver ofta utökad eller krympande påverkansradie, stegvis återställning eller produktspecifik återställning. För intern rapportering, registrera både leverantörens officiella tidslinje och ditt eget observerade påverkansfönster.
Den starkaste lärdomen från 2025 om motståndskraft är att en avbrottsplan bör ha mer än ett 30-minutersläge. En kortvarig störning kan bara kräva kommunikation och tålamod. En händelse som varar flera timmar kräver köarbete och kontrollerade manuella processer. En störning som varar i flera dagar, som den nämnda Marketing Cloud-databasincidenten, kräver personalöverlämningar, hantering av eftersläpningar, kundkommunikation och en återhämtningsplan för uppskjutna kampanjer, import, export, API-drift och rapportering.
Definiera återställningsprioriteringar före ett avbrott. För en säljorganisation kan intag av leads och kundåtaganden komma innan analyserna uppdateras. För en återförsäljare kan orderregistrering, lagernoggrannhet och kundserviceinsikt vara den kritiska vägen. För ett marknadsföringsteam kan prioriteten vara att förhindra dubbletter och bevara kampanjens status snarare än att försöka tvinga fram varje schemalagd aktivitet genom ett instabilt system.
Använd retrospektiven för att testa antaganden, inte för att förutsäga nästa fel. Incidenterna 2025 visar att det inledande problemet kan komma från trafiktryck, leverantörsnätverk, fysisk kylning, databaser, DNS, CDN-konfiguration eller programvaruändringar. Ingen enskild lösning täcker alla dessa.
En mogen Salesforce-kontinuitetsplan bör därför mappa affärsprocesser till tekniska beroenden, tilldela reservägare, definiera säkra återförsöksbeteenden, hålla Salesforce Trust-övervakning nära incidentens arbetsflöde och inkludera en formell avstämningsfas efter tjänståterställning. Det mest användbara måttet är inte bara "tid tills Salesforce blev grönt". Det är tiden tills affärsprocessen verifierades från början till slut och orderstocken rensades på ett säkert sätt.
Denna retrospektiv utarbetades från Salesforces egna Trust- och Help-register och fokuserar på utvalda incidenter från kalenderåret 2025. Salesforce publicerade många andra incidentmeddelanden under året, inklusive kortare och mer snävt avgränsade händelser. Vissa Trust-sidor uppdaterades efter den initiala händelsen i takt med att konsekvensfönster och berörda komponenter förtydligades. För aktuell tjänsthälsa, använd Salesforce Trust Status snarare än att förlita sig på en historisk artikel.
Granska anmärkningsvärda Salesforce-avbrott under 2025, vad som misslyckades, hur länge utvalda incidenter varade och de praktiska lärdomar om motståndskraft som team kan tillämpa.
Skapa en praktisk Salesforce-plan för kontinuitet i driftstopp med konsekvensanalys, RTO/RPO-mål, manuella lösningar, integrationskontroller och återställningskontroller.
Lär dig hur du kontaktar Salesforce Support under ett större avbrott: kontrollera förtroendestatus, välj rätt kanal, öppna ett starkt ärende och spåra återställningen.
Felsök Salesforce Workbench-inloggning, REST Explorer, timeout, 503, API-version och begränsa fel under driftstopp med en praktisk diagnostisk checklista.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Förstå de främsta orsakerna till utbredda driftstopp i molnet, hur fel uppstår i flera steg, vad man ska kontrollera först och hur man utformar en mer motståndskraftig återställningsplan.
Om Datorama eller Marketing Cloud Intelligence verkar vara nere, använd den här evidensbaserade checklistan för att verifiera avbrottet, skydda rapporteringskvaliteten och veta när data är tillförlitliga igen.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Förstå hur Salesforce och AWS kopplas samman via Hyperforce, integrationer, nätverk, datalagring, avbrott och delat driftsansvar.
Ett AWS-avbrott betyder inte automatiskt att Salesforce ligger nere. Lär dig hur Hyperforce, regioner, instanser och Salesforce Trust avgör om din organisation påverkas.
