Under de tidiga timmarna den 27 augusti 2026 drabbades Proton av ett omfattande avbrott som påverkade tjänsterna för ett antal användare. Den bakomliggande orsaken var ett totalt haveri i kylsystemet i vårt datacenter i Frankfurt. Även om alla system hos Proton är redundanta och vi har tillräcklig kapacitet för att hantera ett fullständigt haveri i ett datacenter, finns det ett litet antal scenarier där redundansväxlingen kan ta längre tid och leda till störningar för användarna.

Här är en tidslinje över vad som hände, vilka val vi gjorde under incidenten och varför, samt hur den löstes.

Tidslinje

Strax efter kl. 23.00 (centraleuropeisk tid) onsdagen den 26 augusti inträffade ett kylsystemhaveri i huvudsalen i vårt datacenter i Frankfurt. Runt kl. 23.15 började temperaturen stiga från cirka 21,8 °C (nominell temperatur) till 51,9 °C på mindre än en halvtimme, och vissa mätgivare rapporterade en lufttemperatur på 60 °C i rummet. I takt med att temperaturen steg började server- och nätverksutrustning i anläggningen att sluta fungera en efter en.

Incidenten som påverkade användarna började runt midnatt den 27 augusti, när problemen eskalerade så pass att kritisk redundans förlorades. Detta inträffade när både den primära nätverksswitchen och reservswitchen i ett kritiskt rack havererade, och detta rack innehöll tyvärr flera primära databaskopior. Medan nästan alla Protons system är redundanta och växlas över automatiskt/omedelbart, utförs failover för primära databaser inte automatiskt utan mänsklig övervakning.

Vi behåller denna kontroll för att undvika så kallade “split-brain”-situationer, där en tillfällig otillgänglighet hos en primär databas gör att replikakopiorna missar vissa uppdateringar och blir osynkroniserade på sätt som kan vara svåra att åtgärda i efterhand. Dessutom är standardrutinen vid en primär databas-failover att växla över till en replika i samma datacenter av latens- och prestandaskäl. Problemets specifika karaktär innebar dock att detta kunde vara oklokt, eftersom vi potentiellt kunde växla över till något som också skulle gå ner.

Besluten

I det här läget behövde Protons jourhavande tekniker fatta ett par avgörande beslut under extrem press.

  • Skulle de prioritera att få igång tjänsten online igen, eller prioritera att åtgärda kylningsproblemet och rädda hårdvaran i datacentret?
  • Borde vi växla över till repliker inom samma byggnad i Frankfurt (snabbare och mindre störande, men eventuellt en tillfällig lösning om värmen inte kunde fås under kontroll), eller växla över till Zürich?
  • Ska vi växla över allt eller bara det som ligger nere för tillfället? Vi har beredskap för fullständiga datacenterhaverier där system växlar över helt och hållet och i stort sett automatiskt ganska snabbt, men en situation där servrar slumpmässigt slutar fungera en efter en hanteras inte väl av vår failover-logik.

I slutändan tvingade den hastighet med vilken temperaturen steg oss att prioritera att rädda hårdvaran framför att få tjänsterna online igen. Detta är inte ett val som vanligtvis behöver göras, eftersom kylsystem oftast är redundanta och en total förlust av kylning är mycket sällsynt, vilket innebär att det normalt finns gott om tid innan temperaturerna blir kritiska. Problemet förvärras av de senaste årens kraftiga ökning av effekttätheten i servrar med mer strömkrävande processorer och grafikprocessorer för AI. Som ett resultat blev det som tidigare tog 3–4 timmar att bli kritiskt nu kritiskt på 20 minuter.

Jourteamet fokuserade därför sin uppmärksamhet på att kommunicera med datacentrets driftteam på plats för att återställa kylningen samtidigt som de stängde av så många servrar som möjligt för att skydda dem. På grund av brist på serverutrustning kopplad till den pågående AI-boomen skulle mycket av denna utrustning – om den gick förlorad – inte gå att ersätta med kort varsel. Att rädda den var tvunget att prioriteras, även till priset av potentiellt längre driftstopp.

Vid 00:45 CEST kunde vi återställa kylningen och temperaturen i anläggningen började sjunka, varpå jourteamet skiftade fokus till att återställa tjänsterna. I detta skede fattade vi beslutet att växla över de primära databaserna till Frankfurt om en replika fortfarande fungerade, och till Zürich i de fall där ingen replika fungerade i Frankfurt, för att undvika att ändra våra trafikflöden för mycket och eventuellt skapa ny instabilitet. Detta alternativ valdes eftersom vi antog att det, nu när vi hade kylningen under kontroll, skulle vara relativt enkelt att få Frankfurt online igen och snabbare än att växla över till Zürich.

Tyvärr visade det sig inte vara fallet. Under incidenten nådde många nätverkskort i Frankfurts infrastruktur en temperatur på 105 °C (normal driftstemperatur är 45 °C), vilket utlöser ett särskilt temperaturskyddsläge och gör att nätverkskorten inaktiveras tills en kall omstart av systemet genomförs. Vår säkerhetshållning begränsar möjligheten att få åtkomst till out-of-band-kontrollern för våra system, vilket krävde att vi väckte ytterligare personal för att hjälpa till med återställningen.

Vid 01:30 CEST kunde vi få de flesta tjänster online igen för de flesta användare. Vissa mindre kritiska system, såsom pushaviseringar eller betalningshantering, återställdes dock inte förrän runt kl. 02:00 CEST.

Som vi rapporterade i den inledande incidentrapporten förlorades inga e-postmeddelanden, men e-postleveransen i båda riktningarna fördröjdes under incidenten.

Även om de användarvända tjänsterna var fullt återställda var natten inte över för våra tekniker, särskilt inte för databasteamet. Vår infrastruktur lämnades i ett mycket onormalt tillstånd, med vissa primära databaser i Zürich och andra i Frankfurt, och flera av dem kördes med reducerad redundans och/eller försämrad prestanda. Vårt team arbetade hela natten för att lösa de mest akuta problemen, och arbetet fortsatte under dagen den 27 augusti för att återställa full redundans.

Även om vi kunde rädda nästan hela infrastrukturen drabbades vissa servrar tyvärr av värmedöd, och vi vet ännu inte om värmeincidenten kommer att påverka livslängden för den överlevande utrustningen.

Bakomliggande orsak och nästa steg

En efterföljande utredning den 27 augusti spårade den bakomliggande orsaken till kylningshaveriet till ett luftfilterbyte på båda de redundanta luftkompressorer som driver kylsystemet. Tyvärr utförde datacenteroperatören detta arbete mitt i natten, utan förvarning, och misslyckades dessutom med att meddela kylningshaveriet när det inträffade, vilket dramatiskt minskade tiden vi hade på oss att reagera. Vi har ett nära samarbete med operatören för att förhindra att denna incident upprepas.

Det är dock också en känd begränsning i vår nuvarande databasinfrastruktur att ett avbrott av denna typ kan leda till en längre återställningsprocess än normalt. Den serie händelser som ledde till denna incident är högst osannolik – men ändå inträffade den.

Arbetet med databasens motståndskraft som krävs för att hantera denna feltyp pågår redan och planeras fortfarande vara klart vid årets slut. Ytterligare infrastrukturkapacitet, inklusive nytt datacenterutrymme, driftsätts också för närvarande och förväntas bli tillgängligt inom de närmaste veckorna, vilket ytterligare kommer att minska vårt beroende av en enskild anläggning.

Tyvärr inträffade denna incident innan dessa förbättringar var helt på plats. Vi ser nu över var vi på ett säkert sätt kan påskynda det återstående arbetet samtidigt som vi bibehåller den noggrannhet som krävs vid ändringar i kritisk databasinfrastruktur.

Vi inser att våra användare förväntar sig en mycket hög nivå av tillförlitlighet från Proton, och denna incident understryker vikten av att slutföra detta arbete och fortsätta höja våra standarder för motståndskraft. Vi ber återigen, förbehållslöst, om ursäkt till varje användare som påverkades.