Salesforce-avbrudd i 2025 fulgte ikke ett enkelt mønster. Noen hendelser var begrenset til bestemte instanser eller produkter, mens andre krysset flere skyer eller var avhengige av tredjepartsinfrastruktur. For drifts-, IT-, CRM-, handel- og markedsføringsteam er det nyttige tilbakeblikket ikke en liste over alle Trust-innlegg som ble publisert det året. Det er en gjennomgang av avbruddene som avdekker tilbakevendende feilmoduser: autentiseringsavhengigheter, datasenterinfrastruktur, databasegjenoppretting, innholdsleveringsnettverk, DNS for skyleverandører og endringer som må rulles tilbake.
Denne referansen fokuserer på et utvalg av betydelige hendelser fra 2025, dokumentert av Salesforce Trust. «Stor» betyr her operasjonelt bemerkelsesverdig på grunn av varighet, bredde eller typen kundearbeidsflyt som ble berørt. Det betyr ikke at alle kunder ble berørt, og det er ikke en fullstendig hendelsesopptelling. Den nøyaktige effekten avhenger av produkt, instans, region og leietaker.
| Dato | Hva Salesforce rapporterte | Rapportert varighet eller gjenopprettingsvindu | Hvorfor det er viktig operasjonelt |
|---|---|---|---|
| 7. februar | Tjenesteavbrudd for en delmengde av kunder, der Salesforce oppgir ressursbegrensninger knyttet til høy utnyttelse av nettverkstrafikk. | 2 timer og 20 minutter | Kapasitet og trafikkpress kan føre til redusert ytelse og fullstendig utilgjengelighet. |
| 13.–14. februar | Tjenesteavbrudd knyttet til et problem hos en tredjepartsleverandør; Salesforce sa at leverandøren fant skade på den fysiske nettverksinfrastrukturen mens Salesforce jobbet med failover. | 1 time og 45 minutter | Ekstern tilkobling kan bli en del av den effektive tilgjengelighetsgrensen for Salesforce. |
| 10.–11. juni | En hendelse i flere skyer påvirket autentisering og tjenester på tvers av produkter, inkludert Heroku, Commerce, Marketing Cloud og andre Salesforce-tjenester. | Én Trust-hendelse varte i 22 timer og 43 minutter | Identitet og delte plattformavhengigheter kan skape bred forretningspåvirkning, selv når individuelle applikasjoner forblir funksjonelle. |
| 18.–19. juni | En feil i kjølesystemet ved datasenteret i Indianapolis utløste et nettverksavbrudd; Salesforce rapporterte at de fleste serverne i de mest berørte serverne gikk offline før trinnvis gjenoppretting. | Tjenesteavbruddsfasen rapportert som 18 timer og 44 minutter på den siterte hendelsen | Fysiske anlegg, strøm, nettverk, virtuell infrastruktur, databaser og applikasjonsgjenoppretting kan danne en lang avhengighetskjede. |
| 2.–6. oktober | Marketing Cloud-kunder på databasen DB10016 mistet tjenesten fordi databasen ikke var tilgjengelig; Salesforce jobbet seg gjennom databasegjenoppretting og validering. | Tjenesteavbruddsfase rapportert som 3 dager 16 timer før den går over til ytelsesforringelse | Gjenoppretting av databaser kan være mye tregere enn omstart av applikasjoner, så kontinuitetsplaner trenger en langsiktig modus. |
| 20. oktober | Flere Salesforce-skyer ble påvirket av et DNS-problem hos en tredjepartsleverandør av skyinfrastruktur. Commerce Cloud, MuleSoft, Marketing Cloud Account Engagement, Heroku og andre tjenester rapporterte om relatert innvirkning. | Varierte etter tjeneste; den oppgitte handelsforstyrrelsen varte i 3 timer og 19 minutter, mens en MuleSoft-hendelse forble åpen i 16 timer og 23 minutter. | En avhengighet på enkelt leverandørnivå kan skape forskjellige symptomer og gjenopprettingstider på tvers av produkter. |
| 18. november | En delmengde av Commerce Cloud-butikker opplevde periodiske HTTP 500-feil. Salesforce sa at plattformen og nettverket deres fungerte normalt, og tilskrev forstyrrelsen til en konfigurasjonsoppdatering fra en tredjeparts CDN-leverandør som ble rullet tilbake. | 4 timer og 40 minutter | Kunderettet tilgjengelighet kan svikte i leveringskanten, selv når kjerneplattformen for applikasjonen er i god stand. |
Kildeposter: Salesforce Trust-hendelse 13702 , Salesforce Trust-hendelse 13729 , Salesforce Trust-hendelse 10014307 , Salesforce Trust-hendelse 10014353 , Salesforce Trust-hendelse 20003296 , Salesforce Trust Commerce Cloud-hendelse 20003368 , Salesforce Trust MuleSoft-hendelse 20003364 og Salesforce Trust Commerce Cloud-hendelse 20003465 .
Salesforce Trust rapporterer hendelser etter produkt, instans, tjeneste og noen ganger etter database eller regional komponent. Forstyrrelsen 7. februar påvirket en delmengde av kunder. Marketing Cloud-hendelsen 2. oktober fokuserte på én database. Hendelsen 20. oktober spredte seg over flere skyer, men ga forskjellige gjenopprettingstider og symptomer. For respondenter er det første nyttige spørsmålet derfor ikke bare om Salesforce er nede, men hvilken leietaker, produkt, region, instans og avhengighet som feiler.
Salesforce tilbyr en måte å finne en organisasjons status ved hjelp av Mitt domene-navnet. Den offisielle støtteartikkelen forklarer hvordan du bruker siden for tillitsstatus til å finne instansspesifikk status- og vedlikeholdsinformasjon: Salesforce-hjelp: få organisasjonsstatus og vedlikeholdsdatoer med Mitt domene .
Flere hendelser fra 2025 viser hvorfor SaaS-kontinuitetsplanlegging ikke kan stoppe ved SaaS-leverandørgrensen. Hendelsen 13.–14. februar involverte en tredjeparts nettverksleverandør. Multi-cloud-forstyrrelsen 20. oktober var knyttet til et DNS-problem hos en tredjeparts leverandør av skyinfrastruktur. 18. november rapporterte Salesforce tilkoblingsproblemer for Commerce Cloud-butikkfronten knyttet til en konfigurasjonsoppdatering for en tredjeparts CDN-leverandør.
Lærdommen er ikke at tredjeparter iboende er upålitelige. Det er at kundens arbeidsflyter er avhengige av en kjede av tjenester: identitet, DNS, nettverk, innholdslevering, skyinfrastruktur, API-er og applikasjonstjenester. Hendelsesmodellen din bør følge denne kjeden.
Datasenterarrangementet 18.–19. juni er et godt eksempel. Salesforce beskrev gjenoppretting av fysiske og virtuelle ressurser, deretter online sending av databaser og replikaer, validering av dataparametere og gjenoppretting av avhengige tjenester. Databaseforstyrrelsen i Marketing Cloud i oktober gikk også gjennom gjenoppretting, konfigurasjonskontroller, validering og deretter en senere fase med ytelsesforringelse.
Dette skillet er viktig for forretningsteam. «Plattformen er i bedring» betyr ikke nødvendigvis at alle køer er tømt, alle integrasjoner har blitt spilt på nytt, alle butikkvinduer er stabile eller at alle planlagte jobber har blitt kjørt uten problemer.
En nyttig tillitsgjennomgang har tre gjennomganger. Først må du lese de berørte tjenestene og forekomstene. Deretter må du sammenligne den publiserte starttiden med telemetrien din; Salesforce reviderer noen ganger starttider for hendelser etter hvert som undersøkelsene forbedres. For det tredje må du skille tjenesteavbrudd fra ytelsesforringelse eller funksjonsavbrudd. Disse etikettene beskriver forskjellige driftstilstander, og en hendelse på funksjonsnivå kan gjøre at mesteparten av plattformen er brukbar.
Ikke anta at en hendelsesvarighet tilsvarer perioden der alle berørte kunder opplevde identiske symptomer. Salesforce-oppdateringer beskriver ofte utvidet eller krympende påvirkningsradius, trinnvis gjenoppretting eller produktspesifikk gjenoppretting. For intern rapportering, registrer både leverandørens offisielle tidslinje og ditt eget observerte påvirkningsvindu.
Den sterkeste lærdommen fra 2025 om robusthet er at en avbruddsplan bør ha en modus på mer enn 30 minutter. En kortvarig avbrudd krever kanskje bare kommunikasjon og tålmodighet. En hendelse som varer flere timer krever arbeid i kø og kontrollerte manuelle prosesser. En avbrudd som varer i flere dager, slik som den nevnte hendelsen med Marketing Cloud-databasen, krever bemanningsoverdragelser, håndtering av etterslep, kundekommunikasjon og en gjenopprettingsplan for utsatte kampanjer, import, eksport, API-drift og rapportering.
Definer gjenopprettingsprioriteringer før et driftsavbrudd. For en salgsorganisasjon kan inntak av potensielle kunder og kundeforpliktelser komme før analysene oppdateres. For en forhandler kan ordreregistrering, lagernøyaktighet og synlighet av kundeservice være den kritiske veien. For et markedsføringsteam kan prioriteten være å forhindre dupliserte sendinger og bevare kampanjestatusen i stedet for å prøve å tvinge alle planlagte aktiviteter gjennom et ustabilt system.
Bruk retrospektiven til å teste antagelser, ikke til å forutsi neste feil. Hendelsene i 2025 viser at det utløsende problemet kan komme fra trafikkpress, leverandørnettverk, fysisk kjøling, databaser, DNS, CDN-konfigurasjon eller programvareendringer. Ingen enkelt løsning dekker alle disse.
En moden Salesforce-kontinuitetsplan bør derfor kartlegge forretningsprosesser til tekniske avhengigheter, tildele reserveeiere, definere sikker gjentakelsesatferd, holde Salesforce Trust-overvåking tett opp mot hendelsesarbeidsflyten og inkludere en formell avstemmingsfase etter tjenestegjenoppretting. Den mest nyttige målingen er ikke bare «tid til Salesforce ble grønn». Det er tiden til forretningsprosessen ble verifisert fra ende til ende og etterslepet ble trygt fjernet.
Denne retrospektive analysen ble utarbeidet fra Salesforces egne tillits- og hjelperegistreringer og fokuserer på utvalgte hendelser fra kalenderåret 2025. Salesforce publiserte mange andre hendelsesvarsler i løpet av året, inkludert kortere og mer snevre hendelser. Noen tillitssider ble oppdatert etter den første hendelsen etter hvert som konsekvensvinduer og berørte komponenter ble avklart. For gjeldende tjenestetilstand, bruk Salesforce tillitsstatus i stedet for å stole på en historisk artikkel.
Gjennomgå bemerkelsesverdige Salesforce-avbrudd i 2025, hva som feilet, hvor lenge utvalgte hendelser varte, og de praktiske lærdommene om robusthet teamene kan bruke.
Bygg en praktisk kontinuitetsplan for nedetid i Salesforce med konsekvensanalyse, RTO/RPO-mål, manuelle løsninger, integrasjonskontroller og gjenopprettingskontroller.
Learn how to contact Salesforce Support during a major outage: check Trust Status, choose the right channel, open a strong case, and track recovery.
Feilsøk Salesforce Workbench-innlogging, REST Explorer, timeout, 503, API-versjon og begrens feil under nedetid med en praktisk diagnostisk sjekkliste.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Forstå hovedårsakene til utbredt nedetid i skyen, hvordan feil oppstår, hva du bør sjekke først og hvordan du kan utforme en mer robust gjenopprettingsplan.
Hvis Datorama eller Marketing Cloud Intelligence ser ut til å være nede, bruk denne evidensbaserte sjekklisten for å bekrefte driftsstansen, beskytte rapporteringskvaliteten og vite når dataene er pålitelige igjen.
Et praktisk blikk på hvordan Heroku-avbrudd kan påvirke distribuerte apper, dynamoer, ruting, databaser, distribusjoner, Heroku Connect, logger og gjenoppretting.
En praktisk tilbakeblikk på store Salesforce-avbrudd i 2025, inkludert årsaker, tidslinjer, berørte tjenester, lærdommer og kontinuitetstrinn for administratorer.
Et AWS-avbrudd betyr ikke automatisk at Salesforce er nede. Lær hvordan Hyperforce, regioner, instanser og Salesforce Trust avgjør om organisasjonen din er berørt.
