Salesforce-afbrydelser i 2025 fulgte ikke ét enkelt mønster. Nogle hændelser var begrænset til bestemte instanser eller produkter, mens andre krydsede flere clouds eller var afhængige af tredjepartsinfrastruktur. For drifts-, IT-, CRM-, handels- og marketingteams er det nyttige tilbageblik ikke en liste over alle Trust-indlæg, der blev offentliggjort det pågældende år. Det er en gennemgang af de afbrydelser, der afslører tilbagevendende fejltilstande: godkendelsesafhængigheder, datacenterinfrastruktur, databasegendannelse, indholdsleveringsnetværk, cloududbyder-DNS og ændringer, der skal rulles tilbage.
Denne reference fokuserer på et udvalgt sæt af betydelige hændelser fra 2025, dokumenteret af Salesforce Trust. "Større" betyder her operationelt bemærkelsesværdige på grund af varighed, bredde eller den type kundeworkflow, der er berørt; det betyder ikke, at alle kunder var berørt, og det er ikke en komplet optælling af hændelser. Den nøjagtige effekt afhang af produkt, instans, region og lejer.
| Dato | Hvad Salesforce rapporterede | Rapporteret varighed eller genopretningsvindue | Hvorfor det er vigtigt operationelt |
|---|---|---|---|
| 7. februar | Tjenesteforstyrrelser for en delmængde af kunder, hvor Salesforce henviste til ressourcebegrænsninger forbundet med høj netværkstrafikudnyttelse. | 2 timer og 20 minutter | Kapacitet og trafikpres kan forvandle forringet ydeevne til direkte utilgængelighed. |
| 13.–14. februar | Tjenesteafbrydelse relateret til et problem hos en tredjepartsleverandør; Salesforce oplyste, at leverandøren fandt skader på den fysiske netværksinfrastruktur, mens Salesforce arbejdede på failover. | 1 time og 45 minutter | Ekstern forbindelse kan blive en del af den effektive Salesforce-tilgængelighedsgrænse. |
| 10.–11. juni | En multi-cloud-hændelse påvirkede godkendelse og tjenester på tværs af produkter, herunder Heroku, Commerce, Marketing Cloud og andre Salesforce-tjenester. | Én Trust-hændelse varede 22 timer og 43 minutter | Identitet og delte platformafhængigheder kan skabe bred forretningsmæssig indflydelse, selv når individuelle applikationer forbliver sunde. |
| 18.–19. juni | En fejl i kølesystemet i datacentret i Indianapolis udløste en netværksforstyrrelse; Salesforce rapporterede, at de fleste servere i de hårdest ramte stakke gik offline, før den gradvise gendannelse blev gennemført. | Tjenesteafbrydelsesfasen rapporteret som 18 timer og 44 minutter på den nævnte hændelse | Fysiske faciliteter, strøm, netværk, virtuel infrastruktur, databaser og applikationsgendannelse kan danne en lang afhængighedskæde. |
| 2.–6. oktober | Marketing Cloud-kunder på databasen DB10016 mistede tjenesten, fordi databasen ikke var tilgængelig; Salesforce arbejdede sig igennem databasegendannelse og validering. | Tjenesteafbrydelsesfase rapporteret som 3 dage 16 timer før overgang til ydeevneforringelse | Databasegendannelse kan være meget langsommere end genstart af applikationer, så kontinuitetsplaner kræver en langsigtet tilstand. |
| 20. oktober | Flere Salesforce-clouds blev påvirket af et DNS-problem hos en tredjepartsleverandør af cloudinfrastruktur. Commerce Cloud, MuleSoft, Marketing Cloud Account Engagement, Heroku og andre tjenester rapporterede en relateret påvirkning. | Varierede afhængigt af tjenesten; den nævnte handelsforstyrrelse varede 3 timer og 19 minutter, mens en MuleSoft-hændelse forblev åben i 16 timer og 23 minutter | En afhængighed på enkelt udbyderniveau kan skabe forskellige symptomer og genopretningstider på tværs af produkter. |
| 18. november | En delmængde af Commerce Cloud-butikker oplevede periodiske HTTP 500-fejl. Salesforce oplyste, at deres platform og netværk fungerede normalt, og tilskrev afbrydelsen en konfigurationsopdatering fra en tredjeparts-CDN-udbyder, der blev rullet tilbage. | 4 timer og 40 minutter | Kundevendt tilgængelighed kan svigte i leveringskanten, selv når den centrale applikationsplatform er sund. |
Kildeposter: Salesforce Trust-hændelse 13702 , Salesforce Trust-hændelse 13729 , Salesforce Trust-hændelse 10014307 , Salesforce Trust-hændelse 10014353 , Salesforce Trust-hændelse 20003296 , Salesforce Trust Commerce Cloud-hændelse 20003368 , Salesforce Trust MuleSoft-hændelse 20003364 og Salesforce Trust Commerce Cloud-hændelse 20003465 .
Salesforce Trust rapporterer hændelser efter produkt, instans, tjeneste og nogle gange efter database eller regional komponent. Forstyrrelsen den 7. februar påvirkede en delmængde af kunder. Marketing Cloud-hændelsen den 2. oktober var centreret omkring én database. Hændelsen den 20. oktober strakte sig over flere clouds, men medførte forskellige genoprettelsestider og symptomer. For respondenter er det første nyttige spørgsmål derfor ikke blot, om Salesforce er nede, men hvilken lejer, produkt, region, instans og afhængighed der fejler.
Salesforce tilbyder en måde at finde en organisations status ved hjælp af dens Mit domæne-navn. Den officielle supportartikel forklarer, hvordan man bruger siden Tillidsstatus til at finde instansspecifikke status- og vedligeholdelsesoplysninger: Salesforce Hjælp: Hent organisationsstatus og vedligeholdelsesdatoer med Mit domæne .
Adskillige hændelser fra 2025 viser, hvorfor SaaS-kontinuitetsplanlægning ikke kan stoppe ved SaaS-leverandørgrænsen. Hændelsen den 13.-14. februar involverede en tredjeparts netværksleverandør. Multi-cloud-forstyrrelsen den 20. oktober var knyttet til et DNS-problem hos en tredjeparts cloud-infrastrukturleverandør. Den 18. november rapporterede Salesforce problemer med forbindelsen til Commerce Cloud-butikken i forbindelse med en konfigurationsopdatering fra en tredjeparts CDN-udbyder.
Lærdommen er ikke, at tredjeparter i sagens natur er upålidelige. Det er, at kundernes arbejdsgange afhænger af en kæde af tjenester: identitet, DNS, netværk, indholdslevering, cloudinfrastruktur, API'er og applikationstjenester. Din hændelsesmodel bør følge denne kæde.
Datacenterbegivenheden den 18.-19. juni er et godt eksempel. Salesforce beskrev gendannelse af fysiske og virtuelle ressourcer, derefter online bragte databaser og replikaer, validerede dataparametre og genoprettede afhængige tjenester. Oktober måneds databaseforstyrrelse i Marketing Cloud gik ligeledes gennem gendannelse, konfigurationstjek, validering og derefter en senere fase med ydeevneforringelse.
Den sondring er vigtig for forretningsteams. "Platformen er i bedring" betyder ikke nødvendigvis, at alle køer er tømt, alle integrationer er blevet afspillet igen, alle butikker er stabile, eller at alle planlagte job er kørt korrekt.
En nyttig tillidsgennemgang har tre gennemgange. Først skal du læse de berørte tjenester og instanser. Dernæst skal du sammenligne det offentliggjorte starttidspunkt med din telemetri; Salesforce reviderer nogle gange hændelsesstarttider, efterhånden som undersøgelserne forbedres. For det tredje skal du skelne mellem serviceforstyrrelser og ydeevneforringelser eller funktionsforstyrrelser. Disse betegnelser beskriver forskellige driftstilstande, og en hændelse på funktionsniveau kan efterlade det meste af platformen brugbar.
Antag ikke, at en hændelses varighed er lig med den periode, hvor alle berørte kunder oplevede identiske symptomer. Salesforce-opdateringer beskriver ofte udvidelse eller formindskelse af påvirkningsradius, trinvis genoprettelse eller produktspecifik genoprettelse. Registrer både leverandørens officielle tidslinje og dit eget observerede påvirkningsvindue for intern rapportering.
Den stærkeste lektie fra 2025 om robusthed er, at en afbrydelsesplan bør have en 30-minutters tilstand. En kortvarig afbrydelse kræver muligvis kun kommunikation og tålmodighed. En hændelse, der varer flere timer, kræver arbejde i kø og kontrollerede manuelle processer. En afbrydelse, der varer i flere dage, såsom den nævnte Marketing Cloud-databasehændelse, kræver overdragelse af personale, håndtering af efterslæb, kundekommunikation og en genopretningsplan for udskudte kampagner, import, eksport, API-drift og rapportering.
Definer prioriteter for genopretning før et nedbrud. For en salgsorganisation kan indtagelse af leads og kundeforpligtelser komme før opdatering af analyser. For en detailhandler kan ordreregistrering, nøjagtighed i lagerbeholdningen og synlighed af kundeservice være den kritiske vej. For et marketingteam kan prioriteten være at forhindre dubletter og bevare kampagnens tilstand i stedet for at forsøge at tvinge alle planlagte aktiviteter gennem et ustabilt system.
Brug retrospektiven til at teste antagelser, ikke til at forudsige den næste fejl. Hændelserne i 2025 viser, at det udløsende problem kan komme fra trafiktryk, leverandørnetværk, fysisk køling, databaser, DNS, CDN-konfiguration eller softwareændringer. Ingen enkelt løsning dækker alle disse.
En moden Salesforce-kontinuitetsplan bør derfor knytte forretningsprocesser til tekniske afhængigheder, tildele fallback-ejere, definere sikker gentagelsesadfærd, holde Salesforce Trust-overvågning tæt på hændelsesarbejdsgangen og inkludere en formel afstemningsfase efter servicegendannelse. Den mest nyttige måleenhed er ikke blot "tid indtil Salesforce blev grøn". Det er tiden indtil forretningsprocessen blev verificeret fra start til slut, og efterslæbet blev sikkert fjernet.
Denne retrospektive analyse blev udarbejdet ud fra Salesforces egne Trust- og Hjælp-registreringer og fokuserer på udvalgte hændelser fra kalenderåret 2025. Salesforce udgav mange andre hændelsesmeddelelser i løbet af året, herunder kortere og mere snævert afgrænsede hændelser. Nogle Trust-sider blev opdateret efter den første hændelse, efterhånden som konsekvensvinduer og berørte komponenter blev præciseret. For den aktuelle servicetilstand skal du bruge Salesforce Trust Status i stedet for at stole på en historisk artikel.
Gennemgå bemærkelsesværdige Salesforce-nedbrud i 2025, hvad der fejlede, hvor længe udvalgte hændelser varede, og de praktiske erfaringer om modstandsdygtighed, som teams kan anvende.
Byg en praktisk Salesforce-plan for kontinuitet i nedetid med konsekvensanalyse, RTO/RPO-mål, manuelle løsninger, integrationskontroller og genoprettelsestjek.
Lær, hvordan du kontakter Salesforce Support under et større nedbrud: Tjek tillidsstatus, vælg den rigtige kanal, åbn en stærk sag, og spor gendannelse.
Fejlfind Salesforce Workbench login, REST Explorer, timeout, 503, API-version og begræns fejl under nedetid med en praktisk diagnostisk tjekliste.
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å de vigtigste årsager til udbredt nedetid i skyen, hvordan fejl opstår i flere omgange, hvad man skal kontrollere først, og hvordan man designer en mere robust genopretningsplan.
Hvis Datorama eller Marketing Cloud Intelligence ser ud til at være nede, kan du bruge denne evidensbaserede tjekliste til at verificere nedbruddet, beskytte rapporteringskvaliteten og vide, hvornår data er troværdige igen.
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.
Et AWS-nedbrud betyder ikke automatisk, at Salesforce er nede. Lær, hvordan Hyperforce, regioner, instanser og Salesforce Trust afgør, om din organisation er berørt.
