Konklusjon: Salesforce hadde ikke ett eneste «avbrudd i 2025». Det opplevde en rekke vesentlig forskjellige avbrudd: et problem med Commerce Cloud-utgivelsen, kortvarig forringelse av kjernetjenesten, autentiseringsfeil som krysset skygrenser, en kjølefeil i datasenteret, en langvarig hendelse med e-posttjenester og en senere DNS-relatert avbrudd på tvers av skyen. Den praktiske lærdommen er at tilgjengelighet må evalueres på nivået til den berørte instansen, stakken, tjenesten, integrasjonen og arbeidsflyten – ikke bare ved å spørre om «Salesforce» er oppe.
Salesforces Trust-nettsted er det primære referansepunktet for kommunikasjon om tjenestetilgjengelighet og vedlikehold. Hendelsesregistreringene skiller mellom en ytelsesforringelse, der brukere fortsatt kan nå tjenesten, men noen funksjoner er trege eller upålitelige, og en tjenesteavbrudd, der sluttbrukere kanskje ikke får tilgang til tjenesten. Denne skillet er viktig fordi et CRM kan se ut til å være online mens innlogging, e-postbehandling, søk, API-er eller bakgrunnsjobber mislykkes.
Denne gjennomgangen fokuserer på hendelser i 2025 som hadde ett eller flere av følgende kjennetegn: påvirkning på flere skyer, et langt eller operasjonelt betydelig gjenopprettingsvindu, en rotårsak knyttet til infrastruktur eller endringsledelse, eller en publisert rotårsaksanalyse. Det er ikke en fullstendig opptelling av alle lokaliserte ytelseshendelser registrert i løpet av året. Tidspunktene nedenfor er i UTC med mindre annet er angitt, og varighetsetiketter følger Salesforces hendelsesregistreringer der det er tilgjengelig.
| Dato | Primærområde | Hva kundene så | Dokumentert årsak eller status |
|---|---|---|---|
| 14. januar | Commerce Cloud / B2C Core | Ytelsesproblemer med Order Search API som påvirker jobbaktivitet, butikkaktivitet og ordrebehandling; 12 timer og 45 minutter i hendelsesloggen. | En nylig utgivelse ble identifisert som den potensielle utløseren; Salesforce implementerte senere en løsning. |
| 11. mars | Kjernetjeneste | En kortvarig ytelsesforringelse som varer i omtrent 20 minutter, med mulig treg respons, tidsavbrudd eller uregelmessig tilkobling. | Den offentlige hendelsesrapporten bekrefter gjenoppretting, men etablerer ikke en detaljert underliggende årsak i materialet som er gjennomgått her. |
| 10.–11. juni | Autentisering på tvers av flere skyer, inkludert Heroku | Noen kunder opplevde feil med flerfaktorautentisering og problemer med å logge på Salesforce-relaterte tjenester; hendelsesloggen strekker seg over 22 timer og 43 minutter. | Herokus gjennomgang av korrigerende tiltak identifiserte en utilsiktet leverandørimplementert systemoppdatering av produksjonsinfrastrukturen som den underliggende årsaken til Heroku-avbruddet. |
| 18.–19. juni | Marketing Cloud-engasjement, spesielt Stack 1 og 6 | Tilgangsproblemer, påloggingsfeil og trinnvis gjenoppretting som påvirker applikasjon, bakgrunnsbehandling, e-post og mobiltjenester. | En feil i kjølesystemet ved Salesforces datasenter i Indianapolis førte til at mange fysiske og virtuelle servere ble koblet fra. |
| 26.–27. juni | E-posttjenester | Forsinkelser i innkommende og utgående e-post, køvekst, trege Apex-jobber, returer, leveringsfeil og mulige dupliserte e-post-til-sak-oppføringer. | En utløsende hendelse med høyt volum forbrukte e-postserverressurser og forårsaket en storm av nye forsøk. Salesforce erklærte hendelsen som løst 27. juni klokken 22:08 UTC. |
| 20. oktober | Flere Salesforce-skyer | En omfattende forstyrrelse som påvirker tilgang og skyfunksjoner, med gjenoppretting som skjer i etapper. | Salesforce beskrev et DNS-problem hos en tredjepartsleverandør av skyinfrastruktur; hendelsen falt sammen med en mye rapportert AWS US-EAST-1 DNS-hendelse. |
14. januar begynte Commerce Cloud-kunder som brukte Commerce Order Search API-er å oppleve redusert ytelse. Salesforces hendelseslogg viser B2C Core som den berørte tjenesten, identifiserer starten omtrent klokken 01:30 UTC og registrerer løsningen klokken 14:15 UTC. Effekten var ikke begrenset til en sakte lastet side: avhengig av implementeringen kunne kunder se redusert jobbaktivitet, butikkaktivitet og ordrebehandling.
Rapporten sier at en nylig utgivelse var den potensielle utløseren, og bemerker at noen poder i Asia og Stillehavsregionen mottok den problematiske utgivelsen tidligere enn først antatt. Denne detaljen er viktig for administratorer: et «utgivelsesproblem» påvirker kanskje ikke alle poder samtidig. Kontroll på instansnivå, utgivelsestidspunkt og den nøyaktige API-banen er mer nyttige enn en global ja-eller-nei-antagelse om tilgjengelighet. Se den offisielle hendelsesrapporten for januar .
Hendelsen 11. mars var mye kortere, og tillitsrapporten viste omtrent 20 minutter med ytelsesforringelse for kjernetjenesten. Korte hendelser er enkle å avvise etter gjenoppretting, men de kan fortsatt føre til mislykkede nettleserforespørsler, forsinkede API-kall, dupliserte klientforsøk og forvirring når en brukers skjerm fungerer mens en integrasjon ikke gjør det. Det praktiske poenget er ikke å blåse opp en kort forringelse til et globalt driftsavbrudd; det er å bevare nok telemetri til å avgjøre om en mislykket transaksjon faktisk ble utført.
Fordi den offentlige registreringen som er gjennomgått her ikke gir en detaljert teknisk rotårsak, bør den ikke tilskrives en distribusjon, database, nettverk eller kundekonfigurasjon uten ytterligere bevis. Det er en nyttig disiplin for hendelsesrapportering: skill mellom det statusregistreringen bekrefter og det som forblir ukjent. Referansen er Trust-hendelsen 11. mars .
10. juni rapporterte Salesforce et tjenesteavbrudd som påvirket flere skyer, inkludert Commerce Cloud, Marketing Cloud, Hyperforce og Heroku. Hendelsesrapporten beskriver påvirkning av autentisering og mulige feil med flerfaktorautentisering. Kunder kan støte på påloggingsproblemer selv om en enkelt applikasjon eller et datalager ikke i seg selv var den feilende komponenten.
Herokus senere gjennomgang av korrigerende tiltak legger til den tydeligste detaljen om rotårsaken: en utilsiktet systemoppdatering utført på produksjonsinfrastrukturen av en leverandør endret driftsmiljøet. Heroku sa at hendelsen også påvirket statusstedet, og skapte et kommunikasjonsproblem samtidig som kundene trengte oppdateringer. Korrigerende tiltak inkluderte å stoppe uovervåkede oppgraderinger av leverandøroperativsystemer, revisjon av avbildninger, forbedring av nettverkets oppstartsatferd, styrking av statusstedets robusthet og utvidelse av canary- og regresjonstesting.
Hendelsen i Marketing Cloud den 18. juni er en påminnelse om at SaaS-pålitelighet i siste instans avhenger av fysiske fasiliteter. Salesforce rapporterte at en feil i kjølesystemet ved datasenteret i Indianapolis utløste et nettverksavbrudd som påvirket Stack 1 og 6. Mange fysiske og virtuelle servere gikk offline. Backupgeneratorer støttet miljøet i en periode, og gjenoppretting krevde mer enn bare å gjenopprette strømmen: teamene brakte lagring, nettverkskomponenter, databasesystemer, replikaer og applikasjonstjenester tilbake i en kontrollert rekkefølge.
Hendelsesloggen viser trinnvis gjenoppretting, med Stack 1 gjenopprettet før Stack 6 og nedstrømseffekter på tjenester som Mobile Connect. Salesforces logg strekker seg over nesten 24 timer, men det mest alvorlige vinduet for tjenesteavbrudd og det bredere vinduet for ytelsesforringelse var ikke identiske. Denne forskjellen forklarer hvorfor noen brukere kunne rapportere gjenoppretting mens andre fortsatt opplevde forsinkede sendinger, registreringsproblemer eller utilgjengelige funksjoner. Hovedreferansen er hendelsen i datasenteret i Indianapolis 18. juni .
Den mest driftsmessig lærerike hendelsen i 2025 var forringelsen av e-posttjenestene som ble dokumentert i Salesforces senere rotårsaksanalyse. En utløsende hendelse forbrukte et stort volum av e-postserverressurser. Tregere behandling førte til at eksterne leverandører gjorde flere tilkoblingsforsøk, noe som førte til en storm av nye forsøk. Feil på e-postserveren, forsinkede innkommende og utgående meldinger og ytelsesproblemer for sekundære meldingskøer fulgte.
Gjenoppretting krevde flere samtidige tiltak: deaktivering av problematisk trafikk, omstart av e-posttjenester med køer flyttet til standby-lagring, tillegg av kapasitet, optimalisering av nettverkskonfigurasjon med en tredjepartsleverandør av Mail Transfer Agent, separering av innkommende og utgående trafikk på tvers av verter, migrering av køfiler til SSD-er og bruk av brannmurbegrensning. Salesforce advarte om at permanente e-postfeil ikke ville bli gjenopprettet automatisk, og at nye forsøk kunne opprette dupliserte e-post-til-sak-oppføringer. Den publiserte rotårsaksanalysen er spesielt verdifull fordi den beskriver både den første utløseren og de sekundære effektene.
Den 20. oktober beskrev Salesforces hendelsesrapport en omfattende forstyrrelse på tvers av flere skyer forårsaket av et DNS-problem hos en tredjepartsleverandør av skyinfrastruktur. DNS er katalogsystemet som hjelper programvare med å finne tjenesteendepunkter. Hvis en kritisk oppslagssti mislykkes, kan applikasjoner vise tidsavbrudd eller tilkoblingsfeil selv om de underliggende forretningsdataene ikke har gått tapt.
Samme dag identifiserte AWS' folkehelseinformasjon DNS-løsningsproblemer for regionale DynamoDB-tjenesteendepunkter i US-EAST-1. De to postene bør leses sammen, men ikke slås sammen tilfeldig: Salesforces statusside er autoriteten for Salesforce-påvirkning, mens AWS' helsepost beskriver hendelsen i oppstrømsinfrastrukturen. Salesforce-referansen er hendelsesposten fra 20. oktober , og den tilsvarende oppstrømsreferansen er AWS-helsehendelsen .
2025 brakte også med seg viktige Salesforce-relaterte sikkerhetsrapporter, inkludert kampanjer som involverte kompromitterte tredjeparts OAuth-tokener. Disse hendelsene er relevante for robusthet, men de er ikke det samme som et tilgjengelighetsbrudd. I sin veiledning fra august 2025 sa Google Threat Intelligence at Salesloft Drift-kampanjen ikke stammet fra en sårbarhet i Salesforce-kjerneplattformen, og anbefalte å gjennomgå integrasjoner, rotere legitimasjon og sjekke Salesforce Event Monitoring-logger. Denne skillet forhindrer at en retrospektiv feilaktig merker datatilgangshendelser som nedetid, eller omvendt, behandler et driftsbrudd som bevis på et brudd. Den opprinnelige veiledningen er tilgjengelig fra Google Threat Intelligence .
Salesforce-avbruddsrapporten i 2025 forstås best som en portefølje av feilmoduser snarere enn en enkelt pålitelighetshistorie. Utgivelser kan påvirke spesifikke poder. Autentisering kan mislykkes på tvers av ellers forskjellige skyer. Et kjølesystem kan bli en CRM-hendelse. E-postetterslep kan forsterke seg selv gjennom nye forsøk. En DNS-feil hos en tredjepart kan krysse organisasjonsgrenser.
For kunder er den varige responsen lagdelt synlighet og kontrollert gjenoppretting: vit nøyaktig hvilke Salesforce-tjenester som kjører hvilke forretningsprosesser, overvåk relevant statusomfang, hold nye forsøk trygge, bevar bevis og verifiser data etter gjenoppretting. Disse trinnene vil ikke eliminere nedetid for leverandøren, men de kan redusere forskjellen mellom et kort avbrudd og en langvarig forretningshendelse.
Denne artikkelen ble undersøkt og kontrollert mot Salesforces Trust-statustjeneste , hendelsesregistreringene lenket ovenfor, Salesforces publiserte rotårsaksanalyse av e-posttjenester, Herokus gjennomgang av korrigerende tiltak, Google Threat Intelligence og AWS Health Dashboard. Gjennomgangen ble utarbeidet 16. september 2026. Hendelsessider kan oppdateres etter første publisering, så lesere som undersøker en ny hendelse bør bruke det aktive Trust-nettstedet og sine egne instansspesifikke varsler.
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.
