Det snabbaste och mest tillförlitliga sättet att kontrollera om Salesforce upplever ett omfattande avbrott är att börja med den officiella webbplatsen för Salesforce Trust Status och sedan jämföra den listade incidentomfattningen med din egen instans. Om Salesforce rapporterar störningar i många instanser, tjänster eller regioner är det starka bevis på ett utbrett plattformsproblem. Om det bara är din organisation som misslyckas medan din instans är markerad som tillgänglig är orsaken mer sannolikt organisationsspecifik, integrationsrelaterad, identitetsrelaterad eller lokal för ditt nätverk.
Det finns en viktig begränsning: Salesforce behöver inte märka en händelse som "globalt avbrott" för att den ska vara allvarlig, och ett problem som påverkar många kunder kan fortfarande vara begränsat till specifika produkter, instanser eller regioner. Det praktiska målet är därför att fastställa omfattningen , inte bara att leta efter en enda global ja-eller-nej-indikator.
Gå först till Salesforce Trust Status . Salesforce beskriver Trust Status som webbplatsen för att lära sig om tillgänglighet och prestanda för Salesforce-produkter. Dess nuvarande dokumentation säger att hemsidan visar pågående incidenter och underhållshändelser över Salesforce-instanser och -tjänster.
Öppna avsnittet Incidenter och titta på händelseinformationen. Salesforce säger att en incidentpost kan visa händelsestatus, berörda instanser och tjänster, start- och sluttider och ytterligare uppdateringar. De officiella instruktionerna finns i Kontrollera pågående incidenter eller underhåll .
Anta till exempel att ditt säljteam i USA inte kan läsa in kontoposter. Om Trust visar ett avbrott i Core Service som påverkar en lång lista med instanser i USA, Europa och Asien-Stillahavsområdet, pekar bevisen mot en bred incident på Salesforce-sidan. Om incidenten bara påverkar en Commerce Cloud POD och du använder Sales Cloud på en annan instans, förklarar den händelsen förmodligen inte ditt symptom.
En global incidentlista är användbar, men du behöver fortfarande veta om din organisation ingår i det berörda omfånget. Salesforce rekommenderar att du identifierar den instans som är värd för organisationen.
Om du kan komma åt Salesforce-inställningarna, säger Salesforces riktlinjer från den 4 augusti 2026 att du ska öppna inställningarna , söka efter företagsinformation och hitta fältet instans i organisationsdetaljer. Om du inte kan komma åt Salesforce kan du använda din domän på webbplatsen för förtroendestatus. Salesforce säger att du ska ange domännamnet i sökfältet för förtroende och visa instansen som returneras bredvid det.
Källan för dessa steg är Visa instansinformation för din Salesforce-organisation .
Om din inloggnings-URL för Min domän är något i stil med https://example.my.salesforce.com, dokumenterar Salesforce också att du kan söka efter Förtroende med hjälp av namnet Min domän istället för hela inloggnings-URL:en. Se Hämta din organisationsstatus och kommande underhållsdatum med Min domän .
När du väl är på instanssidan, stanna inte vid en grön eller röd ikon. Salesforce dokumenterar fyra viktiga statuskategorier för en instans:
Salesforce förklarar dessa statusar i Visa din instans status .
Denna distinktion är särskilt viktig när folk rapporterar att "Salesforce är nere" trots att de fortfarande kan logga in. Långsamma sökningar, timeouts, försenade integrationer, otillgängliga Experience Cloud-sidor eller en felaktig Service Cloud-funktion kan motsvara en prestandaförsämring eller tjänstespecifik incident snarare än ett fullständigt instansavbrott.
Du kan nu klassificera problemet med hjälp av de bevis du har samlat in.
| Vad du observerar | Den mest rimliga tolkningen | Vad man ska göra härnäst |
|---|---|---|
| Många instanser och regioner förekommer i en aktiv förtroendeincident | Bred störning på Salesforce-sidan | Följ tidslinjen för incidenten och interna kontinuitetsrutiner |
| Din instans finns med i en aktiv incident, men andra regioner är felfria | Instans- eller regionspecifikt Salesforce-problem | Spåra händelsen och undvik att kalla den global |
| En Salesforce-tjänst är försämrad medan andra tjänster fortfarande är tillgängliga | Tjänstspecifik incident | Använd opåverkade funktioner där det är praktiskt möjligt och övervaka den tjänsten |
| Din instans är tillgänglig och ingen matchande incident finns | Inte tillräckligt med bevis för ett Salesforce-omfattande avbrott | Kontrollera din organisationskonfiguration, identitetsleverantör, integrationer, webbläsare, DNS, VPN och lokalt nätverk |
En användbar regel är: ju bredare den bekräftade förtroendepåverkan är över orelaterade instanser, tjänster och regioner, desto starkare är argumenten för att beskriva händelsen som utbredd. Men undvik att överdriva bevisen. Ett dussin drabbade instanser i en region kan vara stora utan att vara globala. På samma sätt kan en incident som sträcker sig över flera moln påverka en stor kundpopulation utan att störa alla Salesforce-produkter.
Leta efter flera signaler tillsammans snarare än en ledtråd:
Inget av dessa bevisar att alla Salesforce-kunder världen över är drabbade. Tillsammans ger de dock en mycket bättre grund för att beskriva händelsens omfattning.
Resultatet "Tillgänglig" betyder att Salesforce för närvarande inte rapporterar en störning på instansnivå under den statusen, men det bevisar inte att alla problem du upplever är imaginära eller lokala. Vissa problem kan vara intermittenta, begränsade till en delmängd av användare, knutna till en integration eller associerade med en tjänst som behöver kontrolleras separat.
Börja med att jämföra användare och nätverk. Om alla i ditt företag misslyckas men externa webbplatser fungerar, testa Salesforce från ett annat nätverk eller en annan enhet om dina säkerhetspolicyer tillåter det. Om bara användare bakom en viss VPN, proxy, DNS-resolver eller identitetsleverantör påverkas, begränsar det utredningen.
Isolera sedan integrationerna. Om Salesforce-sidor laddas men en automatisering som anropar ett externt API misslyckas, kan avbrottet ligga i integrationsvägen snarare än i Salesforce Core. Om inloggningen bara misslyckas via enkel inloggning medan direkt autentisering beter sig annorlunda, förtjänar ditt identitetslager uppmärksamhet.
Hemsidan för Trust separerar incidenter från underhåll. Salesforce tillhandahåller även underhållsinformation på instanssidor. Planerat underhåll kan tillfälligt påverka en tjänst, men det bör inte presenteras som ett oväntat globalt avbrott om inte Salesforce rapporterar en separat incident.
När du kontrollerar en statuspost, jämför dess typ och tidsstämplar med dina symptom. Om underhåll var schemalagt för en annan instans eller inträffade timmar innan problemet började, är det osannolikt att det är orsaken.
Salesforces nuvarande dokumentation om förtroende innehåller en viktig produktspecifik anmärkning. Webbplatsen för förtroendestatus visar data från instanser för Salesforce-produkter generellt, men Salesforce hänvisar kunder till Salesforce My Trust Center för vissa produkter, inklusive Agentforce 360 Platform, Data 360, Salesforce AI och Marketing Cloud Engagement, och för produktionsmiljöer för vissa Agentforce-produkter och Salesforce Industries.
Du kan granska det aktuella omfånget i Salesforce Hjälp: Förtroendestatus . Detta är viktigt eftersom en administratör som bara kontrollerar en offentlig statusvy kan missa produktspecifik information som Salesforce nu visar via Mitt förtroendecenter.
Om Salesforces tillgänglighet är operativt viktig för din organisation, konfigurera förtroendemeddelanden före nästa incident. Salesforce säger att förtroendemeddelanden kan ge e-post- eller SMS-meddelanden i nästan realtid om serviceproblem, underhållshändelser och produktversioner som publiceras i förtroendestatus.
Salesforces dokumentation om incidentkommunikation beskriver även ytterligare kommunikationskanaler för incidenter, inklusive uppdateringar om förtroende, informationsmeddelanden, hjälpbanners, e-postmeddelanden med incidentvarningar till administratörer och livewebbinarier för kritiska incidenter.
Aviseringar är särskilt användbara för driftsteam eftersom de minskar fördröjningen mellan att en incident publiceras och att någon upptäcker den manuellt.
Tänk dig att klockan 9:05 rapporterar alla på ett kontor att Salesforce inte laddar. Ett globalt avbrott är bara en möjlig förklaring.
Öppna först Salesforce Trust. Det finns inga incidenter som påverkar din instans. Kontrollera sedan instanssidan så visas Tillgänglig. Anställda som arbetar hemifrån kan komma åt Salesforce normalt, men användare på kontorsnätverket kan inte. Andra webbplatser är också intermittenta.
I den situationen stöder inte tillgängliga bevis att händelsen kan kallas ett globalt Salesforce-avbrott. Den mer troliga nästa undersökningen är kontorsnätverket, DNS, proxy, brandvägg eller anslutningsväg.
Ändra nu exemplet: Salesforce Trust visar en störning i kärntjänsten som påverkar många instanser i flera regioner, din instans visas i incidenten och användare på flera nätverk ser samma fel. Det är starka bevis på en bred incident på Salesforce-sidan. Du kan sedan fokusera på kontinuitetsprocedurer och officiella uppdateringar snarare än att spendera den första timmen på att byta webbläsare eller starta om användarenheter.
Innan du skickar ett internt meddelande om att "Salesforce är globalt nere", kontrollera fyra saker:
Om dessa kontroller pekar på bred påverkan på flera instanser, beskriv avbrottet exakt: till exempel ”Salesforce rapporterar ett avbrott i kärntjänsten på flera instanser som påverkar flera regioner”. Den formuleringen är mer korrekt än att säga ”Salesforce är globalt nere” om inte bevisen verkligen stöder global påverkan.
För att kontrollera om Salesforce upplever ett globalt avbrott, använd Salesforce Trust som primär källa, identifiera din egen instans, inspektera de berörda instanserna och tjänsterna i den aktiva incidenten och jämför den geografiska omfattningen med dina symtom. Om många orelaterade instanser och regioner påverkas är incidenten bred. Om bara din organisation misslyckas medan Salesforce rapporterar din instans som tillgänglig, undersök lokala och organisationsspecifika beroenden innan du skyller på ett globalt plattformsavbrott.
Nyckeln är precision. Salesforces tillgänglighet rapporteras per instans och tjänst, så det mest tillförlitliga svaret kommer från att matcha den officiella incidentomfattningen med din egen miljö snarare än att förlita sig på sociala inlägg, generiska avbrottspåståenden eller en enda misslyckad inloggning.
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.
