Ti deploys om dagen. Ét af dem er dårligt. Polylane finder det og ruller det tilbage.
Skriv dig på ventelistenHvert deploy overvåges, fra start. Hvad der blev ændret, hvem der ændrede det, og de signaler der mest sandsynligt går i stykker.
SQS visibility timeout lowered on checkout-events
VisibilityTimeout on checkout-events dropped from 120s to 15s. Consumers that hold a message longer than 15 seconds will see it delivered twice; the dead-letter queue threshold is unchanged.
Rollback, hvis du vil have det. Slået fra som standard. Slå det til, og en agent klarer resten.
Critical latency degradation in checkout-edge worker
Critical latency degradation detected in checkout-edge worker: 18x+ P99 latency spikes sustained for 12 minutes
Deploy 9f3c2a1 shrank the Hyperdrive pool
hd-prod from 50 connections to 5. Under checkout load,
requests queue on connection checkout and P99 rises 18× against the 30-minute baseline. Restoring the pool size restores latency.
Rul tilbage nu. Ret ordentligt bagefter. Rollbacken køber tid: den rigtige rettelse følger til din gennemgang.
Cap retries on the checkout webhook worker #491
polylanemain from polylane/autofix/chat/k3x9f2-4e7d21a Retries on the checkout webhook worker were unbounded: a failing delivery re-queued itself forever and amplified load on payments-api. This caps delivery at 5 attempts with exponential backoff and dead-letters the payload after the last one.
What changed
worker/deliver.ts gains MAX_DELIVERY_ATTEMPTS = 5 and backoff between attempts; exhausted payloads land in checkout-webhooks-dlq instead of re-queueing.
Validation
npm test — 214 passed. A forced failing delivery stopped after 5 attempts and appeared in the dead-letter queue.
Sådan virker Polylane. Den lærer dit system, holder øje med det, undersøger og handler.
-
Den lærer dit system først
Kontekstgrafen kortlægger hver ressource og afhængighed på tværs af dine clouds, repositories og observability-udbydere. Agenter ræsonnerer over rigtig topologi, ikke gæt.
-
Detektion uden tærskler
Indbyggede kontroller for hver udbyder, plus kontroller genereret fra dine egne gemte queries og dashboards. En statistisk gennemgang og en agent beslutter sammen, og en forbedring rejser aldrig et issue.
-
Undersøgelser, der viser beviser
Hver påstand linker tilbage til den query, loglinje eller ændringspost, der ligger bag. En vurdering uden beviser falder tilbage til uafgjort.
-
Skrivninger skal gøres fortjent, aldrig antages
Konti forbindes skrivebeskyttet. Rollbacks er slået fra som standard, rate-begrænsede og registrerede. Kodeændringer går gennem din normale gennemgang.
-
Den bliver skarpere hver uge
Minder, daglige noter og overvågnings-queries genbekræftet mod rigtige data: julis undersøgelse lærer af junis.
Den kobler sig på det, du allerede kører. Forbind skrivebeskyttet og kom i gang.
Spørgsmål.
Hvilke platforme kan Polylane rulle tilbage?
Deployments på Cloudflare, Vercel, Render og Fly.io, hvor det sidste kendte gode deploy genskabes. Rollbacks er slået fra som standard: du slår dem selv til og kan slå dem fra når som helst.
Hvad forhindrer et automatisk rollback-loop?
Hårde grænser i platformen, ikke agentens dømmekraft. Tre vellykkede rollbacks i timen pr. mål, én rollback i gang ad gangen, og når parallelle gennemgange er uenige om, hvilken version der skal genskabes, blokeres handlingen og eskaleres til dig.
Har den brug for min CI-pipeline?
Nej. Polylane læser deploys fra udbyderne selv. Gennemgangen af pull requests kører som en GitHub-kontrol, du kan gøre påkrævet, men intet i din pipeline ændres.
Hvad med ændringer, der ikke er deploys?
Konfigurationsændringer, skaleringsevents og sikkerhedsændringer registreres og overvåges på samme måde. Når en kø opfører sig forkert tolv minutter efter, at nogen sænkede dens visibility timeout, starter undersøgelsen fra den ændring.
Kan jeg se, hvorfor en rollback skete?
Hver rollback har beviser: den kørsel, der lavede den, de signaler, der regredierede, den version, der blev genskabt, og begrundelsen lander i posten.