Samenvatting
Op 19 januari 2026, tussen 14:02 en 14:28 UTC, mislukte ongeveer tweederde van alle pogingen om in te loggen op het paneel of te authenticeren tegen de API. Bestaande sessies werden ook willekeurig ongeldig gemaakt. Draaiende instances, hun netwerk en hun verkeer werden gedurende het hele incident niet geraakt. Provisioning pauzeerde zesentwintig minuten en liep daarna leeg; geen enkele bestelling ging verloren.
Tijdlijn
Alle tijden UTC, 19 januari 2026.
| Tijd | Gebeurtenis |
|---|---|
| 14:02 | Wijziging aan het sessietoken-schema toegepast op het control plane. Rollout gemarkeerd als configuratie, dus ging naar alle zes paneelnodes tegelijk. |
| 14:03 | Login-foutpercentage stijgt van bijna nul naar eenenzestig procent. Geautomatiseerde alerting heeft een venster van twee minuten en vuurt nog niet. |
| 14:06 | Alert vuurt. Dienstdoende engineer opgeroepen. |
| 14:08 | Eerste responder online. Ziet een foutpercentage, geen deploy in de code-wijzigingslog, en begint naar de database te kijken. |
| 14:14 | Tweede engineer sluit aan, controleert de configuratiewijzigingslog in plaats van de codelog, en vindt de vermelding van 14:02. |
| 14:16 | Oorzaak begrepen: twee nodes valideren tokens met de vorige reader. |
| 14:19 | Rollback begint. |
| 14:24 | Tokens worden correct uitgegeven en gevalideerd op alle zes nodes. Foutpercentage daalt naar nul. |
| 14:28 | Wachtrij voor provisioning leegt. Herstel voltooid. |
| 15:10 | Statuspagina bijgewerkt. Tweeënveertig minuten te laat, wat op zichzelf een falen is en hieronder wordt behandeld. |
Oorzaak
Het sessietoken kreeg een veld. Schrijvers zonden onmiddellijk het nieuwe formaat; de reader op twee van de zes paneelnodes was niet herstart en verwierp alles met het nieuwe veld. Verzoeken worden verdeeld over alle zes nodes, dus een sessie aangemaakt op een nieuwe node had ruwweg een kans van één op drie om bij een willekeurig verzoek door een oude te worden gevalideerd. Het resultaat leek intermitterend, daarom gingen de eerste zes minuten van de diagnose naar de database in plaats van naar de deploylog.
De diepere oorzaak is een regel die we in 2023 schreven. Wijzigingen die een schema-bestand raken in plaats van applicatiecode werden geclassificeerd als configuratie, en configuratie sloeg de canary-fase over op grond van het feit dat het, citaat, gewoon waarden waren. Die regel was redelijk toen de enige schema-bestanden feature flags waren. Niemand herzag het toen de definitie van een schema-bestand uitbreidde, en deze wijziging werd correct geclassificeerd onder een regel die stilzwijgend verkeerd was geworden.
Het was geen fout van de engineer die het toepaste. De classificatie werd precies gevolgd zoals geschreven.
Omvang
- Paneellogins: eenenzestig procent foutpercentage gedurende zesentwintig minuten.
- API-tokens: zelfde foutpercentage, zelfde venster. Idempotentiesleutels zorgden ervoor dat opnieuw uitgevoerde aanmaakverzoeken geen duplicaten opleverden.
- Draaiende instances: niet geraakt. Geen pakketverlies, geen herstarts, geen opslageffect.
- Provisioning: gepauzeerd, niet mislukt. Vier bestellingen werden tijdens het venster afgerond en alle vier voltooid om 14:28.
Wat we hebben gewijzigd
- De canary-fase is nu onvoorwaardelijk. Alles wat deployt, van welke classificatie dan ook, gaat eerst vijf minuten naar één node met synthetisch verkeer voordat het ergens anders naartoe gaat. Gedaan op 21 januari.
- Readers accepteren het vorige formaat gedurende dertig dagen. Tokenvalidatie is nu expliciet geversioneerd met een overlapvenster, dus een gedeeltelijk uitgerolde wijziging degradeert tot helemaal niets. Gedaan op 23 januari.
- Een synthetische login draait elke vijftien seconden vanuit ons netwerk, in drie regio's, en paget bij de tweede opeenvolgende fout in plaats van na een middelingvenster van twee minuten. Gedaan op 22 januari.
- De statuspagina publiceert automatisch wanneer de synthetische login twee keer faalt, zonder te wachten op een mens om een zin te schrijven. Een menselijke zin volgt daarna. Gedaan op 26 januari.
Wat we niet hebben gewijzigd, en waarom
We loggen nog steeds geen klant-IP's of verzoeklichamen voor paneelverkeer. Die zouden onmiddellijk de verdeling van één op drie over nodes hebben getoond en waarschijnlijk negen minuten hebben bespaard. Negen minuten is niet waard dat we permanent vastleggen waar elke klant inlogt. De bewaartabel op de logpagina blijft ongewijzigd.
We hebben sessies niet verplaatst naar een gedeelde cross-site-opslag. Een enkele sessieopslag over alle sites zou het probleem van gemengde readers volledig hebben vermeden door één reader te hebben. Het zou ook precies het gecentraliseerde, altijd-hete bestand van wie verbonden is met wat creëren dat we zes jaar lang niet hebben opgebouwd.
We hebben geen uitvalaankondigingskanaal buiten de statuspagina toegevoegd. Verschillende mensen stelden sociale media voor. De statuspagina is het enige dat we beheren waarvan we kunnen garanderen dat het accuraat blijft, en een tweede oppervlak toevoegen betekent een tweede oppervlak dat verouderd raakt.
Het tegoed
De SLA dekt instance-beschikbaarheid. Instances waren beschikbaar gedurende alle zesentwintig minuten, dus onder het contract was niemand iets verschuldigd. We hebben een tegoed van één dag toegepast op elk account dat een mislukte authenticatie had tijdens het venster, wat neerkwam op ongeveer drieduizend honderd euro, omdat discussiëren over het onderscheid met mensen die hun servers niet konden bereiken een slechter gebruik is van ieders middag.