De belangrijkste conclusie uit de Salesforce-storingen van 2025 is dat er geen sprake was van één enkele, jaarbepalende "wereldwijde Salesforce-storing". Klanten ondervonden in plaats daarvan verschillende verstoringspatronen: een brede serviceonderbreking in februari, authenticatieproblemen in meerdere clouds in juni, een groot incident op het Heroku-platform veroorzaakt door een onbedoelde update van de leverancier, een netwerkstoring in een datacenter in Indianapolis en latere incidenten die beperkt bleven tot specifieke instanties of functies. Dat onderscheid is belangrijk, omdat de juiste reactie afhangt van wat er precies misging.
Als gebruikers niet kunnen inloggen, lost een browserverversing het probleem niet op. Als de openbare statuspagina vertraagd is, kan een algemene storingmonitor ook onvolledig zijn. Als Salesforce beschikbaar is, maar een integratiewachtrij vastloopt, kan het CRM-systeem zelf er gezond uitzien, terwijl de bedrijfsprocessen nog steeds niet goed functioneren. De praktische les van 2025 is om tenantspecifieke statusmeldingen, onafhankelijke monitoring, geteste handmatige procedures en een herstelcontrole voor downstream-systemen te combineren.
De volgende incidenten zijn nuttig voor een terugblik, omdat ze verschillende faalmodi illustreren. Dit is geen bewering dat elke Salesforce-statusgebeurtenis in 2025 hier is opgenomen.
| Datum | Ontregeling | Wat de gegevens aantonen | Waarom het belangrijk is |
|---|---|---|---|
| 7 februari | Dienststoring | Volgens het officiële incidentverslag eindigde de storing om 11:21 UTC en duurde deze ongeveer 2 uur en 20 minuten. | Een grootschalige servicegebeurtenis kan de normale werking van Salesforce beïnvloeden, zelfs als de onderliggende oorzaak niet openbaar bekend is. |
| 10 juni | Authenticatieproblemen tussen verschillende clouds | Salesforce meldde dat de authenticatieservices voor Heroku, Commerce, Marketing Cloud en Salesforce-services hierdoor beïnvloed werden. | Afhankelijkheden tussen inloggegevens en identiteitsgegevens kunnen leiden tot een storing die meerdere producten treft, zonder dat elk product dezelfde technische fout vertoont. |
| 10 juni | De verstoring van het Heroku-platform | Heroku schreef het incident later toe aan een onbedoelde systeemupdate die door een leverancier op de productie-infrastructuur was toegepast. Ook de Heroku-statuswebsite werd getroffen. | Het communicatiekanaal kan onderdeel van het incident worden, waardoor onafhankelijke meldingskanalen essentieel zijn. |
| 18 juni | Netwerkstoring in datacenters in Indianapolis | Salesforce meldde dat een storing in het koelsysteem van het datacenter in Indianapolis gevolgen had voor Stacks 1 en 6. | Storingen in de fysieke infrastructuur kunnen weliswaar beperkter zijn dan een wereldwijde stroomstoring, maar toch ernstige gevolgen hebben voor de betrokken instanties. |
| 1 november | Storing van de kernservice op instantieniveau | Het officiële incidentrapport identificeert IND76 als een getroffen instantie en registreert het incident als opgelost. | Instantiespecifieke controles zijn nuttiger dan alleen te vertrouwen op algemene rapporten als "Is Salesforce offline?". |
| 31 december | Verslechtering van de prestaties van WhatsApp-berichten | Salesforce meldde dat de WhatsApp-berichtenfunctie op meerdere apparaten problemen ondervond met de prestaties en bevestigde later, om 16:56 UTC, dat het probleem was opgelost. | Een bepaalde functie kan uitvallen, terwijl de rest van het CRM-systeem bruikbaar blijft. |
Voor de incidenten in februari en het Salesforce Trust-incident zijn de data, de omvang en de herstelupdates afkomstig uit de incidentenrapporten van Salesforce: de serviceonderbreking van 7 februari , het incident met de authenticatie tussen clouds op 10 juni , het incident in Indianapolis op 18 juni , het incident met de instantie op 1 november en het WhatsApp-incident op 31 december .
10 juni is bijzonder belangrijk omdat de term 'Salesforce-storing' meerdere gebeurtenissen kan beschrijven. In het Trust-rapport van Salesforce werden problemen met multifactorauthenticatie beschreven die verschillende clouds troffen. Het latere correctieve actierapport van Heroku beschreef een verstoring van de platformservice die om 06:00 UTC begon en werd veroorzaakt door een onbedoelde systeemupdate die door een leverancier op de productie-infrastructuur was toegepast.
Heroku erkende ook dat de statuspagina getroffen was. Volgens de update met corrigerende maatregelen van Heroku leidden ontwerpfouten in de statuspagina en API-latentie tot time-outs, waardoor de pagina soms geen actieve incidenten leek weer te geven. Heroku gaf aan dat het hierop reageerde met maatregelen zoals een permanente stopzetting van onbeheerde upgrades van besturingssystemen van leveranciers, image-audits, extra monitoring, het cachen van statuscontent, onafhankelijke communicatieplanning en strengere procedures voor incidentafhandeling.
Dit is een waardevol onderscheid voor beheerders. Een statuspagina is niet de service zelf, maar klanten gebruiken deze om te beslissen of ze moeten wachten, overschakelen naar een andere service, een supportaanvraag openen of met hun eigen gebruikers communiceren. Als het statuskanaal te veel infrastructuur deelt met het betreffende platform, biedt het mogelijk geen betrouwbaar overzicht op het moment dat dit het meest nodig is.
Een team kan over intacte applicatiegegevens beschikken en toch niet kunnen werken als de login, multifactorauthenticatie of een gekoppeld identiteitspad mislukt. Dit is met name belangrijk voor bedrijven die Salesforce, Heroku, Commerce en Marketing Cloud combineren. Documenteer welke gebruikers toegang nodig hebben tot welke systemen, identificeer contactpersonen voor noodgevallen die updates van de leverancier kunnen ontvangen en definieer welke werkzaamheden kunnen worden voortgezet zonder een succesvolle login.
Voor een klein verkoopteam kan dat een tijdelijke, handmatig bijgehouden bellijst en een gedeeld incidentenlogboek betekenen. Voor een contactcenter of zorginstelling kan het een formele procedure voor uitval, goedgekeurde alleen-lezen exports en een geteste escalatiestructuur vereisen. De omvang van de noodoplossing moet overeenkomen met de zakelijke gevolgen van een eventuele uitsluiting.
De documentatie van Salesforce zelf legt uit dat de vertrouwensstatus informatie geeft over beschikbaarheid en prestaties, terwijl de nieuwere weergaven in Mijn Vertrouwenscentrum zijn ontworpen rond tenants en ondersteunde producten. Het operationele punt is eenvoudig: ken uw instantie- of tenant-ID voordat er een incident optreedt.
Salesforce biedt ook instructies voor het abonneren op berichten en meldingen van Mijn Vertrouwenscentrum . Configureer meldingen voor de personen die actie moeten ondernemen, niet alleen voor de beheerder die de organisatie oorspronkelijk heeft aangemaakt. Zorg voor een onafhankelijk kanaal, zoals een interne statuspagina of een goedgekeurde berichtengroep, zodat uw bedrijf kan blijven communiceren, zelfs als een statuspagina van een leverancier traag of niet beschikbaar is.
Wanneer Salesforce meldt dat de services zijn hersteld, kan het incident nog steeds gevolgen hebben voor de bedrijfsvoering. Een vertraagde API-aanvraag kan twee keer opnieuw worden geprobeerd, een bericht in de wachtrij kan te laat aankomen of een mislukte implementatie kan ervoor zorgen dat records niet meer gesynchroniseerd zijn. Controleer na het herstel de workflows die er het meest toe doen: authenticatie, API-aanroepen, geplande taken, integratiewachtrijen, e-mail- of berichtenbezorging, het aanmaken van records en de actualiteit van rapportages.
Stel je bijvoorbeeld een middelgroot supportteam voor waarvan de medewerkers Salesforce-cases gebruiken, terwijl een apart e-commercesysteem updates verstuurt via een integratie. Als Salesforce om 10:00 uur weer beschikbaar is, maar de integratiewachtrij nog steeds foutmeldingen bevat uit het storingsvenster, mag het team het incident niet sluiten alleen omdat de browser laadt. De juiste test is of nieuwe en eerder mislukte case-updates het volledige workflowproces doorlopen zonder duplicatie.
| Bedrijfsomstandigheden | Praktisch minimum | Wanneer moet je meer toevoegen? |
|---|---|---|
| Klein team; een korte onderbreking is acceptabel. | Abonneer u op relevante Trust-meldingen, noteer de instantie-ID en houd een korte checklist bij voor handmatige werkzaamheden. | Voeg export- en hersteltests toe als klantgeschiedenis of nalevingsgegevens cruciaal zijn. |
| Omzet, contactcenteractiviteiten of serviceverlening zijn de hele dag afhankelijk van Salesforce. | Gebruik onafhankelijke monitoring, een downtimeprocedure, controlemechanismen voor het opnieuw proberen van integraties en een aangewezen incidentverantwoordelijke. | Test failover of alternatieve invoerkanalen tijdens kantooruren vóór een daadwerkelijke storing. |
| Salesforce is gekoppeld aan Heroku of meerdere cloudomgevingen. | Monitor de statusbron en documenteer de authenticatieafhankelijkheden van elk product afzonderlijk. | Voer gezamenlijke hersteloefeningen uit waarbij inloggen, API's, wachtrijen en klantcommunicatie gezamenlijk worden getest. |
| Gereguleerde of waardevolle gegevens | Gebruik een goedgekeurd back-up- en bewaarplan, toegangsbeheer, audit trails en een herstelhandleiding. | Laat het draaiboek beoordelen door de afdelingen beveiliging, juridische zaken, compliance en bedrijfsleiding. |
Begin met een afhankelijkheidskaart van één pagina. Noteer uw Salesforce-instantie of -tenant, identiteitsprovider, verbonden clouds, kritieke integraties, statusabonnementen en het handmatige proces dat tijdens een storing wordt gebruikt. Definieer vervolgens een objectieve herstelcontrole voor elke belangrijke workflow. "Salesforce is weer online" is te vaag; "nieuwe cases, uitgaande berichten en orderupdates worden verwerkt zonder duplicaten" is testbaar.
Bekijk tot slot de wijzigingen die de beschikbaarheid kunnen beïnvloeden: updates van leveranciers, wijzigingen in het besturingssysteem, releases, configuratiewijzigingen en instantiemigraties. Het Heroku-incident in juni laat zien waarom onbeheerde wijzigingen sterke controlemechanismen vereisen en waarom statuscommunicatie ook veerkrachtig moet zijn. De gebeurtenis van 18 juni laat zien waarom fysieke capaciteit en afhankelijkheden van datacenters nog steeds van belang zijn voor een cloudservice. De functievermindering in december laat zien waarom teams de functies die ze daadwerkelijk gebruiken moeten monitoren, en niet alleen de algemene beschikbaarheid van het platform.
De meest geschikte reactie is daarom voorwaardelijk. Een kleine organisatie heeft mogelijk meldingen en een duidelijke handmatige checklist nodig. Een bedrijf dat de verkoop of ondersteuning niet kan stilleggen, heeft onafhankelijke monitoring, herstel op basis van wachtrijen en een geoefend proces voor downtime nodig. Een sterk gereguleerde organisatie heeft geteste herstelprocedures, bewijsmateriaal en governance nodig. De gegevens over de Salesforce-storingen in 2025 ondersteunen één consistente conclusie: veerkracht is gebouwd rond de afhankelijkheidsketen van de klant, niet rond een enkele groene statusindicator.
Deze terugblik maakt gebruik van incidentregistraties van Salesforce Trust en de documentatie van Salesforce of Heroku die beschikbaar was op het moment van schrijven. Incidentpagina's kunnen na de oplossing worden bijgewerkt en de productdekking van Salesforce verschilt tussen Trust Status en My Trust Center. Waar Salesforce geen gedetailleerde oorzaakanalyse heeft gepubliceerd, wordt deze in dit artikel niet afgeleid.
Een praktische gids voor 2026 over AI, slimme huissensoren, bewaking op afstand, valpreventie, privacy en hoe technologie kan bijdragen aan zelfstandig thuis wonen op latere leeftijd zonder zorg te vervangen.
Leer hoe steden mobiliteits-, landgebruiks-, klimaat- en gemeenschapsgegevens kunnen omzetten in veiligere, groenere en meer beloopbare buurten, zonder technologie boven mensen te stellen.
Vergelijk toonaangevende opleidingen in de lucht- en ruimtevaarttechniek voor drones, autonomie, besturing, UAS-operaties en afstudeeronderzoek, met geverifieerde updates voor 2026.
Een praktische gids voor AI-gestuurde chirurgische robotica: huidige mogelijkheden, mate van autonomie, voordelen op het gebied van precisie, beperkingen, regelgeving en evaluatiecriteria.
Er wordt steeds meer geïnvesteerd in CCUS, maar kan koolstofafvang de wereldwijde uitstoot terugdringen? Ontdek waar het werkt, wat de schaalbaarheid beperkt en welk bewijsmateriaal ertoe doet.
Compare seven global programs for digital supply chains, logistics, analytics, global trade, and operations, with practical guidance on choosing the right fit.
Leer hoe brein-computerinterfaces neurale signalen decoderen om communicatie en beweging te herstellen, wat recente studies hebben bereikt en wat het gebruik van BCI nog steeds beperkt.
See how commercial drones combine sensors, edge AI, batteries, communications, and flight-control software—and where autonomy still depends on mission and regulation.
Vergelijk zeven toonaangevende bedrijven op het gebied van batterijen en energieopslag op basis van materialen, systemen, onderzoek, branche-ervaring, flexibiliteit, taal en kostenafwegingen.
Leer hoe de massa van de lading, de batterijlimieten, het weer, de voortstuwingsefficiëntie en de vliegtuigarchitectuur de vliegduur van industriële UAV's beïnvloeden, en hoe je die kunt verbeteren.
