Root Cause Analysis (RCA) Report

Incident Information

Incident Slogan: Stroomstoring datacenter AMS3 (Amsterdam) verstoort telefonie- en hostingdiensten.

Impact: Op 29 juni 2026 ondervonden klanten die gebruikmaken van diensten via ons datacenter in Amsterdam (AMS3) een storing. Telefonie, hosting- en enkele netwerkdiensten waren circa vier uur niet of beperkt beschikbaar. Aanleiding was een kortstondige stroomonderbreking bij onze datacenterleverancier tijdens gepland onderhoud.

Prioriteit: Major Incident

Starttijd: 29 juni 2026, 14:05

Eindtijd klantimpact: 29 juni 2026, 18:30

Technische nazorg en controles: Afgerond op 30 juni 2026

Incident samenvatting

Op 29 juni 2026 raakte een deel van onze dienstverlening vanuit ons datacenter in Amsterdam (AMS3) verstoord. Aanleiding was een kortstondige stroomonderbreking bij onze datacenterleverancier tijdens gepland onderhoud aan de stroomvoorziening. Hoewel de stroom na circa 17 minuten werd hersteld, was deze korte onderbreking voldoende om een aantal onderliggende systemen uit te laten vallen. Dit betroffen onze telefonie-, database- en opslagomgeving. Onze technische teams hebben direct actie ondernomen, samen met onze datacenterleverancier. De belangrijkste diensten waren binnen ongeveer vier uur weer volledig hersteld. Enkele technische vervolgwerkzaamheden op de achtergrond liepen door tot de volgende dag, zonder verdere impact voor klanten.

Tijdlijn

29 juni, 14:05 – Tijdens gepland onderhoud bij onze datacenterleverancier ontstaat een kortstondige stroomstoring in ons datacenter in Amsterdam (AMS3), waardoor een deel van de netwerkapparatuur uitvalt.
29 juni, 14:15 – De datacenterleverancier start het herstel; onze eigen technici sluiten aan en er wordt ook een technicus ter plaatse gestuurd.
29 juni, 14:22 – De stroom is hersteld. Al snel blijkt dat de korte onderbreking ook andere systemen heeft geraakt, waaronder telefonie, databases en opslag.
29 juni, vanaf ca. 14:40 – Onze technische teams stellen vast dat de impact groter is dan verwacht en starten een breder herstelproces.
29 juni, ca. 15:25 – Om verdere risico’s te beperken, schakelen onze technici resterende apparatuur gecontroleerd uit en weer gericht in.
29 juni, ca. 16:22 – De eerste telefoniediensten herstellen: registraties en gesprekken komen gefaseerd weer op gang. De dienstverlening is op dat moment nog niet volledig hersteld.
29 juni, ca. 18:30 – Telefonie-, database- en hostingdiensten zijn weer volledig beschikbaar voor klanten.
29 juni (avond) – Onze teams controleren de opslagomgeving en vervangen een defect onderdeel.
30 juni – De datacenterleverancier rondt het resterende geplande onderhoud af en bevestigt dat de dubbele stroomvoorziening weer volledig is hersteld.
1 juli – De datacenterleverancier sluit het onderzoek naar de stroomstoring formeel af.

Root Cause

De primaire aanleiding van de storing was een onverwachte stroomonderbreking tijdens gepland onderhoud bij onze datacenterleverancier. De uiteindelijke impact werd vergroot door een interne afhankelijkheid binnen onze database-architectuur.

Deze onderbreking duurde 17 minuten, maar had een grotere impact dan verwacht door twee omstandigheden. Ten eerste was de getroffen stroomaansluiting een extra aansluiting op de hoofdvoeding van die serverkast, in plaats van een volledig onafhankelijke tweede voeding. Tijdens het herstel is vastgesteld dat een coördinerend onderdeel binnen de database-omgeving een afhankelijkheid had met AMS3. Hierdoor kon de database-omgeving op de tweede locatie niet automatisch zelfstandig verder verwerken. Dit ontwerp wordt aangepast door deze functie onder te brengen op een derde, onafhankelijke locatie. Toen dit onderdeel wegviel, kon ook de volledig gezonde database-omgeving op onze andere locatie geen gegevens meer wegschrijven, waardoor telefonie, hosting en andere diensten alsnog uitvielen.

Ook bleek dat er voorafgaand aan de storing geen automatische melding was afgegaan voor dit specifieke stroomonderdeel, en dat het niet op afstand bediend kon worden, waardoor herstel alleen ter plaatse mogelijk was. Onze datacenterleverancier onderzoekt momenteel zelf de precieze technische oorzaak van de doorgeslagen beveiliging.

Incident oplossing

Zodra de stroom weer beschikbaar was, bleek dat de korte onderbreking meerdere systemen had geraakt. Onze technische teams hebben de dienstverlening vervolgens stap voor stap hersteld, in nauwe samenwerking met onze datacenterleverancier.

Eerst is overige apparatuur in het datacenter gecontroleerd afgeschakeld en weer opgestart, om overbelasting van de tijdelijk enige beschikbare stroomvoeding te voorkomen. Daarna is de database-omgeving handmatig opnieuw opgestart, waarna ook de telefonieomgeving kon worden hersteld: bellen en registraties werkten vanaf ongeveer 18:30 uur weer volledig. Een configuratiefout in een onderliggend systeem is gecorrigeerd en een beschadigd onderdeel van de database is opnieuw opgebouwd.

Er zijn geen aanwijzingen gevonden voor dataverlies of blijvende corruptie van klantdata. De uitgevoerde herstelacties hadden betrekking op het opnieuw beschikbaar maken van de database- en opslagomgeving.

Tot slot zijn de opslagsystemen gecontroleerd en is een fysiek defect onderdeel vervangen; de laatste technische controles zijn de volgende dag afgerond. Onze datacenterleverancier heeft het geplande onderhoud eveneens afgerond en bevestigd dat de volledige, dubbele stroomvoorziening weer beschikbaar is.

Mitigerende acties

1. We vragen een formeel onderzoeksrapport op bij onze datacenterleverancier over de doorgeslagen stroombeveiliging en laten de stroomcapaciteit van de betreffende serverkast opnieuw beoordelen.
2. We onderzoeken de mogelijkheid om stroomcomponenten op afstand te kunnen monitoren en bedienen, of maken hierover aanvullende afspraken met onze datacenterleverancier.
3. We verplaatsen het onderdeel van onze database-omgeving dat de synchronisatie tussen locaties verzorgt naar een derde, onafhankelijke locatie, zodat uitval van één datacenter niet meer kan leiden tot dezelfde brede impact op de database-omgeving.
4. We breiden onze controles op berichtenverwerking uit, zodat afwijkingen in de configuratie automatisch worden gesignaleerd.
5. We zorgen voor een centraal en actueel overzicht van noodtoegang tot kritieke systemen, zodat onze technici bij een volgende storing nog sneller kunnen ingrijpen.
6. We voeren een gerichte hersteltest uit op onze database-omgeving om onze procedures verder aan te scherpen.
7. We versterken de toegangsrechten binnen het verantwoordelijke team, zodat een databaseherstel voortaan nog sneller uitgevoerd kan worden.
8. De komende periode zullen we onze manier van communiceren rondom storingen extra onder de aandacht brengen om onze partners en klanten zo goed mogelijk te bereiken in het geval van verstoringen.
9. Gedurende het incident is via de reguliere communicatiekanalen gecommuniceerd over de voortgang. Naar aanleiding van dit incident evalueren wij ook de snelheid en volledigheid van onze incidentcommunicatie richting klanten/partners. De frequentie van updates passen wij aan naar minimaal één update per 30 minuten gedurende een verstoring, ook wanneer er op dat moment nog geen inhoudelijke wijziging te melden is.