In de vroege uren van 27 augustus 2026 kreeg Proton te maken met een grootschalige storing die voor een aantal gebruikers gevolgen had voor de dienstverlening. De hoofdoorzaak was een totale uitval van het koelsysteem in ons datacenter in Frankfurt. Hoewel alle systemen bij Proton redundant zijn en we voldoende capaciteit hebben om een complete datacenteruitval op te vangen, is er een klein aantal scenario’s waarin de failover langer kan duren en kan leiden tot verstoringen voor gebruikers.

Hier volgt een tijdlijn van wat er is gebeurd, welke keuzes we tijdens het incident hebben gemaakt en waarom, en hoe het is opgelost.

Tijdlijn

Vlak na 23.00 uur (Midden-Europese tijd) op woensdag 26 augustus deed zich een storing voor in het koelsysteem in de hoofdzaal van ons datacenter in Frankfurt. Rond 23.15 uur begon de temperatuur in minder dan een half uur te stijgen van ongeveer 21,8 °C (nominale temperatuur) naar 51,9 °C, waarbij sommige meetsondes een luchttemperatuur van 60 °C in de ruimte registreerden. Naarmate de temperatuur opliep, begaf de server- en netwerkapparatuur in de faciliteit het één voor één.

Het voor gebruikers merkbare incident begon rond middernacht op 27 augustus, toen de storingen escaleerden tot het punt waarop kritieke redundantie verloren ging. Dit gebeurde toen zowel de primaire als de back-up netwerkswitch op een cruciaal rack uitviel, en dit rack bevatte helaas verschillende primaire databasekopieën. Hoewel vrijwel alle Proton-systemen redundant zijn en automatisch/onmiddellijk overschakelen (failover), worden failovers van primaire databases niet automatisch uitgevoerd zonder menselijk toezicht.

We behouden deze controle om zogeheten ‘split-brain’-situaties te voorkomen, waarbij een tijdelijke onbeschikbaarheid van een primaire database ertoe leidt dat de replica’s bepaalde updates missen en asynchroon raken op manieren die later moeilijk te herstellen zijn. Bovendien is de standaardprocedure bij een failover van een primaire database om over te schakelen naar een replica in hetzelfde datacenter om redenen van latentie en prestaties. Door de specifieke aard van het probleem was dit echter wellicht onverstandig, aangezien we mogelijk zouden overschakelen naar iets dat ook zou uitvallen.

De beslissingen

Op dat moment moesten de dienstdoende engineers van Proton onder extreme druk een aantal ingrijpende beslissingen nemen.

  • Geven ze prioriteit aan het weer online brengen van de dienst, of geven ze prioriteit aan het aanpakken van het koelingsprobleem en het redden van de hardware in het datacenter?
  • Moeten we een failover uitvoeren naar replica’s in hetzelfde gebouw in Frankfurt (sneller en minder ontregelend, maar mogelijk een tijdelijke oplossing als de hitte niet onder controle kon worden gebracht), of overschakelen naar Zürich?
  • Laten we alles overschakelen of alleen wat er op dat moment uitligt? We hebben noodplannen voor complete datacenteruitval waarbij systemen vrij snel, volledig en grotendeels automatisch overschakelen, maar een situatie waarin willekeurige servers het één voor één begeven, wordt niet goed opgevangen door onze failoverlogica.

Uiteindelijk dwong de snelheid waarmee de temperatuur steeg ons ertoe voorrang te geven aan het redden van de hardware boven het weer online brengen van de diensten. Dit is normaal gesproken geen keuze die gemaakt hoeft te worden, omdat koelsystemen doorgaans redundant zijn en het volledig wegvallen van koeling uiterst zeldzaam is, waardoor er behoorlijk wat tijd is voordat de temperaturen kritiek worden. Het probleem wordt verergerd door de sterke toename van de vermogensdichtheid van servers in de afgelopen jaren, met zwaardere CPU’s en GPU’s voor AI. Daardoor werd wat voorheen 3-4 uur zou duren om een kritiek punt te bereiken, nu binnen 20 minuten kritiek.

Het dienstdoende team richtte zijn aandacht daarom op de communicatie met het operationele team ter plaatse in het datacenter om de koeling te herstellen, terwijl er zoveel mogelijk servers werden uitgeschakeld om ze te beschermen. Vanwege een tekort aan serverapparatuur dat verband houdt met de aanhoudende AI-boom, zou veel van deze apparatuur — indien verloren — op korte termijn niet te vervangen zijn. Het behoud ervan moest prioriteit krijgen, zelfs als dit de uitvaltijd mogelijk zou verlengen.

Rond 00:45 CEST wisten we de koeling te herstellen en begonnen de temperaturen in de faciliteit te dalen, waarna het dienstdoende team zich ging richten op het herstel van de diensten. Op dat moment namen we het besluit om voor de primaire databases een failover uit te voeren naar Frankfurt als er nog een replica actief was, en naar Zürich in gevallen waarin er geen replica meer actief was in Frankfurt, om te voorkomen dat we onze verkeersstromen te veel zouden wijzigen en mogelijk nieuwe instabiliteit zouden creëren. Voor deze optie werd gekozen omdat we aannamen dat het, nu we de koeling onder controle hadden, relatief eenvoudig en sneller zou zijn om Frankfurt weer online te brengen dan over te schakelen naar Zürich.

Helaas bleek dit niet het geval te zijn. Tijdens het incident bereikten veel netwerkkaarten in de infrastructuur in Frankfurt een temperatuur van 105 °C (de normale bedrijfstemperatuur is 45 °C), wat een speciale temperatuurbeveiligingsmodus activeert waardoor de netwerkkaarten worden uitgeschakeld totdat er een cold reset van het systeem wordt uitgevoerd. Ons beveiligingsbeleid beperkt de toegang tot de out-of-band-controller van onze systemen, waardoor we extra medewerkers wakker moesten maken om te helpen bij het herstel.

Tegen 01:30 CEST slaagden we erin om de meeste diensten weer online te krijgen voor de meeste gebruikers. Sommige minder kritieke systemen, zoals pushmeldingen of betalingsverwerking, waren echter pas rond 02:00 CEST hersteld.

Zoals we al meldden in het eerste incidentrapport, zijn er geen e-mails verloren gegaan, maar de e-mailbezorging in beide richtingen was tijdens het incident vertraagd.

Hoewel de diensten voor gebruikers volledig waren hersteld, was dat nog niet het einde van de nacht voor onze technici, met name het databaseteam. Onze infrastructuur bevond zich in een zeer uitzonderlijke staat, met sommige primaire databases in Zürich en andere in Frankfurt, waarvan meerdere werkten met verminderde redundantie en/of verminderde prestaties. Ons team heeft de hele nacht doorgewerkt om de meest urgente problemen op te lossen, en het werk ging op 27 augustus gedurende de dag door om de volledige redundantie te herstellen.

Hoewel we bijna de gehele infrastructuur hebben kunnen redden, hebben sommige servers het helaas door oververhitting begeven, en we weten nog niet of het oververhittingsincident invloed zal hebben op de levensduur van de overgebleven apparatuur.

Hoofdoorzaak en vervolgstappen

Uit nader onderzoek op 27 augustus bleek dat de koelingsstoring werd veroorzaakt door het vervangen van een luchtfilter op beide redundante luchtcompressoren die het koelsysteem aandrijven. Helaas voerde de datacenterbeheerder deze werkzaamheden midden in de nacht uit, zonder voorafgaande kennisgeving, en heeft deze de koelingsuitval niet gemeld toen deze plaatsvond, wat onze reactietijd drastisch beperkte. We werken nauw samen met de beheerder om herhaling van dit incident te voorkomen.

Het is echter ook een bekende beperking van onze huidige database-infrastructuur dat een dergelijke storing kan leiden tot een langer herstelproces dan normaal. De aaneenschakeling van gebeurtenissen die tot dit incident heeft geleid, is hoogst onwaarschijnlijk — maar het is toch gebeurd.

De werkzaamheden aan de veerkracht van de database die nodig zijn om dit type storing aan te pakken, zijn al aan de gang en de afronding staat nog steeds gepland voor het einde van het jaar. Er wordt momenteel ook extra infrastructuurcapaciteit in gebruik genomen, waaronder nieuwe datacenterruimte, die naar verwachting binnen enkele weken beschikbaar zal zijn, waardoor onze afhankelijkheid van één enkele locatie verder zal afnemen.

Helaas vond dit incident plaats voordat die verbeteringen volledig waren doorgevoerd. We bekijken nu waar we de resterende werkzaamheden veilig kunnen versnellen, terwijl we de zorgvuldigheid behouden die vereist is voor wijzigingen in de kritieke database-infrastructuur.

We beseffen dat onze gebruikers een zeer hoge mate van betrouwbaarheid verwachten van Proton, en dit incident benadrukt hoe belangrijk het is om dit werk te voltooien en onze normen voor veerkracht te blijven verhogen. We bieden nogmaals onze oprechte excuses aan aan elke gebruiker die hierdoor getroffen is.