Ti deploys om dagen. Én av dem er dårlig. Polylane finner den og ruller den tilbake.
Bli med på ventelistenHver deploy følges, rett ut av boksen. Hva som ble endret, hvem som endret det, og signalene som mest sannsynlig 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. Av som standard. Slå det på, og en agent tar seg av 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.
Rull tilbake nå. Fiks ordentlig etterpå. Rollbacken kjøper tid: den egentlige fiksen følger til gjennomgangen din.
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.
Slik fungerer Polylane. Den lærer systemet ditt, følger med på det, undersøker og handler.
-
Den lærer systemet ditt først
Kontekstgrafen kartlegger hver ressurs og avhengighet på tvers av skyene, repositoriene og observerbarhetsleverandørene dine. Agenter resonnerer over faktisk topologi, ikke gjetninger.
-
Deteksjon uten terskler
Innebygde sjekker for hver leverandør, pluss sjekker generert fra dine egne lagrede spørringer og dashbord. En statistisk gjennomgang og en agent avgjør sammen, og en forbedring reiser aldri et issue.
-
Undersøkelser som viser belegg
Hver påstand lenker tilbake til spørringen, logglinjen eller endringsoppføringen bak den. En konklusjon uten bevis faller tilbake til uavklart.
-
Skriving må gjøres fortjent, aldri antas
Kontoer kobles til skrivebeskyttet. Rollbacks er av som standard, ratebegrenset og dokumentert. Kodeendringer går gjennom den vanlige gjennomgangen din.
-
Den blir skarpere hver uke
Minner, dagsnotater og overvåkingsspørringer bekreftet på nytt mot ekte data: julis undersøkelse lærer av junis.
Den kobler seg på det du allerede kjører. Koble til skrivebeskyttet og start.
Spørsmål.
Hvilke plattformer kan Polylane rulle tilbake?
Deployments på Cloudflare, Vercel, Render og Fly.io, ved å gjenopprette den siste kjente gode deployen. Rollbacks er av som standard: du slår dem på selv og kan slå dem av når som helst.
Hva stopper en automatisk rollback-løkke?
Harde grenser i plattformen, ikke agentens skjønn. Tre vellykkede rollbacks per time per mål, én rollback i gang om gangen, og når parallelle gjennomganger er uenige om hvilken versjon som skal gjenopprettes, blokkeres handlingen og eskaleres til deg.
Trenger den CI-pipelinen min?
Nei. Polylane leser deploys fra leverandørene selv. Gjennomgangen av pull requester kjører som en GitHub-sjekk du kan kreve, men ingenting i pipelinen din endres.
Hva med endringer som ikke er deploys?
Konfigurasjonsendringer, skaleringshendelser og sikkerhetsendringer registreres og følges på samme måte. Når en kø oppfører seg dårlig tolv minutter etter at noen senket visibility timeout på den, starter undersøkelsen fra den endringen.
Kan jeg se hvorfor en rollback skjedde?
Hver rollback har belegg: kjøringen som gjorde den, signalene som regredierte, versjonen som ble gjenopprettet, og begrunnelsen lander i oppføringen.