Wanneer een afhankelijkheid vastloopt: onze post-mortem van het incident op 22–23 juni

De afgestemde tijdlijn

Tijd (UTC)	Wat er stroomopwaarts gebeurde (Volledig rapport)	Wat intern gebeurde / onze ervaring
22 juni, 19:00	De trigger: capaciteitsgebrek bij AWS in us-east-1 zorgt ervoor dat ~10.000 runs zich ophopen in de upstream-wachtrijen.	Onze achtergrondtaken beginnen stilletjes vast te lopen. Onder water groeien de wachtrijen.
22 juni, 20:09	De meltdown: het Kubernetes-control plane stroomopwaarts bereikt 100% CPU, verliest databasequorum en **us-east-1** valt volledig uit.	Onze productieomgeving stopt met het verwerken van runs. Duizenden taken binnen het hele platform zitten vast in de backlog.
22 juni, 21:58	De engineering van de upstream partij vecht actief tegen een lus van een "reconnection storm".	Incident gemeld: Er worden verhoogde foutpercentages vastgesteld en een interne incidentruimte wordt opgezet.
23 juni, 00:59	De upstream provider raadt gebruikers aan om workloads handmatig over te zetten naar hun regio eu-central-1.	Incidentleider toegewezen: De incidentresponsruimte wordt volledig geactiveerd met een toegewezen leider om de evaluatie tussen regio’s te coördineren.
23 juni, 01:01 - 02:10	De upstream provider voert een noodupdate van het dashboard door zodat runs in bulk tussen regio’s kunnen worden verplaatst.	Actieve mitigatie: Om 01:10 annuleert het team handmatig onze in de wachtrij staande Amerikaanse runs om de geblokkeerde uitvoercapaciteit van ons account vrij te maken en routeert al het nieuwe verkeer naar de Europese regio. Om 02:10 beginnen berichten weer verwerkt te worden.
23 juni, 02:02 - 02:33	De upstream provider schaalt handmatig hun database-opslaglaag op.	Ernst opgehoogd naar kritisch: Meer dan 30.000+ van onze eigen taken staan nu in de wachtrij en wachten. Het team plaatst een kritieke statusupdate op onze openbare statuspagina.
23 juni, 04:35 - 05:05	Upstream-infrastructuurupdates vertragen de uitvoersnelheid weer tot een slakkengang.	De webhook-knelpunt: De verwerkingssnelheid daalt. Om 05:05 zien we dat onze wachtrij voor webhooklevering het belangrijkste knelpunt is dat weigert leeg te lopen.
23 juni, 08:38	De tweede cascade: omgeleid wereldwijd verkeer overspoelt de Europese regio van de provider en legt die volledig plat.	Totale stilstand: Beide upstream-regio’s zijn nu in feite dood. We hebben meer dan 13.000+ taken die bevroren in uitvoering zijn en volledig afhankelijk zijn van herstel stroomopwaarts.
23 juni, 10:34	De engineering stroomopwaarts probeert hun Europese regio weer online te krijgen.	Uitrol van de circuit breaker: Omdat we zien dat de primaire laag voor achtergrondverwerking volledig vastzit, verschuift ons team van infrastructuurmitigatie naar een architecturale omleiding. We zetten een nood-hotfix uit in alle kernapplicatie- en API-omgevingen om asynchrone taakverwerking tijdelijk uit te schakelen.
23 juni, 10:41	De upstream provider is nog steeds bezig met het aanpassen van de nodes van hun control plane.	Directe verlichting: De architecturale omleiding werkt perfect. Door de bevroren achtergrondwachtrijen te omzeilen, vallen kritieke app-processen terug op directe uitvoerpaden. Engineering bevestigt: "Emails stromen weer."
23 juni, 17:06	De upstream provider stabiliseert eindelijk beide regio’s en herstelt de verwerkingssnelheid.	Wachtrij geleegd: Engineering bevestigt dat onze wachtrijen in beide regio’s volledig leeg zijn. De systeemprestaties keren terug naar normaal.
23 juni, 19:31	Stabiliteit na herstel houdt stand.	Incident opgelost: Systemen zijn volledig normaal; het team gaat over naar de flow voor evaluatie na het incident.

Belangrijkste lessen & onze evaluatie van de ervaring

Hoewel de post-mortem stroomopwaarts zich richtte op database-tuning en clusterinfrastructuur, richt onze interne evaluatie zich op graceful degradation en architecturale veerkracht.

1. De kracht van de "kill switch"

Het bepalende moment van ons herstel vond plaats om 10:34 UTC. Toen de secundaire regio van onze provider instortte, schakelden we van proberen de achtergrondwachtrijen te beheren over naar het implementeren van een structurele omleiding.

• De omleiding: Door een globale configuratiewijziging door te voeren om achtergrondtaken uit te schakelen, hebben we in feite de kabel doorgeknipt naar onze kapotte afhankelijkheid. Daardoor moesten kritieke gebruikersacties, zoals bevestigingsmails voor boekingen, tijdelijk de bevroren achtergrondengine omzeilen en direct worden verwerkt.

• Binnen 7 minuten waren de kernprocessen voor onze gebruikers volledig hersteld, wat aantoont dat ingebouwde, schakelbare fallbackpaden voor grote externe afhankelijkheden een niet-onderhandelbare vereiste zijn voor hoge beschikbaarheid.

2. Multi-region concurrency-valstrikken beheren

Tijdens de mitigatiefase bracht het navigeren door een multi-region opzet onverwachte platformbeperkingen met zich mee. Taken die vastzaten in een tussenfase in de Amerikaanse regio bleven onze globale uitvoercapaciteit van het account verbruiken, zelfs nadat we onze applicatie naar Europa hadden gericht.

• Het identificeren en uitvoeren van een gerichte bulk-annulering van de vastgelopen Amerikaanse pool om 01:10 was cruciaal om uitvoercapaciteit vrij te maken in onze nieuw gekozen Europese regio.

3. Verharding tegen de blast radius stroomopwaarts

Hoewel onze noodfallback de dag redde voor bedrijfskritische stromen zoals e-mail, zaten er nog steeds meer dan 13.000+ taken doodvast in bevroren upstream-wachtrijen totdat de provider volledig was hersteld.

• De toekomstige route: Vooruitkijkend beoordelen we het ontwerp van een meer lokale buffer. Voor achtergrondtaken of uitgaande webhooks onderzoeken we de implementatie van een lichte interne staging-wachtrij die taken lokaal kan opslaan tijdens een black-out stroomopwaarts, zodat bij het opnieuw afspelen de juiste volgorde behouden blijft.

Samenvatting

Uiteindelijk heeft ons engineeringteam met succes een complexe multi-region concurrency-valstrik gediagnosticeerd, verkeer omgeleid en een creatieve architecturale omleiding uitgerold die onze gebruikerservaring uren redde voordat onze provider hun infrastructuur wist te stabiliseren.

We weten dat dit een erg moeilijk moment was voor het Trigger.dev-team. We hebben respect voor hen en blijven een geweldige samenwerking hebben. Deze post is bedoeld om simpelweg onze kant van het incident te delen en te laten zien hoe ons team reageerde.