Dix deploys par jour. L'un d'eux est mauvais. Polylane le trouve et l'annule.
Rejoindre la liste d'attenteChaque deploy est surveillé, d'office. Ce qui a changé, qui l'a changé, et les signaux les plus susceptibles de casser.
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.
SetQueueAttributes CloudTrail · deploy-bot · 12:41:02Z attached to this record's delta window Le rollback, si tu le veux. Désactivé par défaut. Active-le, et un agent s'occupe du reste.
Critical latency degradation in checkout-edge worker
checkout-edge › Cloudflare Worker Critical latency degradation detected in checkout-edge worker: 18x+ P99 latency spikes sustained for 12 minutes
edge-gateway Cloudflare Worker ··· checkout-edge Cloudflare Worker ··· 
hd-prod Hyperdrive ··· 
payments-db PlanetScale ··· cart-svc Cloudflare Worker ···
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.
Annule maintenant. Corrige proprement ensuite. Le rollback fait gagner du temps : le vrai correctif suit pour ta revue.
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.
Comment Polylane fonctionne. Il apprend ton système, le surveille, enquête et agit.
-
Il apprend d'abord ton système
Le graphe de contexte cartographie chaque ressource et chaque dépendance à travers tes clouds, tes dépôts et tes fournisseurs d'observabilité. Les agents raisonnent sur une topologie réelle, pas sur des suppositions.
-
Détection sans seuils
Des vérifications intégrées pour chaque fournisseur, plus des vérifications générées à partir de tes propres requêtes enregistrées et de tes dashboards. Une passe statistique et un agent décident ensemble, et une amélioration ne lève jamais d'issue.
-
Des enquêtes qui montrent leurs preuves
Chaque affirmation renvoie à la requête, à la ligne de log ou à l'enregistrement de changement qui la fonde. Un verdict sans preuves retombe sur non concluant.
-
Les écritures se méritent, jamais présumées
Les comptes se connectent en lecture seule. Les rollbacks sont désactivés par défaut, limités en fréquence et consignés. Les changements de code passent par ta revue habituelle.
-
Il s'affûte chaque semaine
Mémoires, notes quotidiennes et requêtes de supervision reconfirmées contre des données réelles : l'enquête de juillet apprend de celle de juin.
Il se branche sur ce que tu fais déjà tourner. Connecte en lecture seule et commence.
Questions.
Quelles plateformes Polylane peut-il annuler ?
Les déploiements Cloudflare, Vercel, Render et Fly.io, en restaurant le dernier deploy connu comme sain. Les rollbacks sont désactivés par défaut : tu les actives toi-même et tu peux les désactiver à tout moment.
Qu'est-ce qui empêche une boucle de rollbacks automatiques ?
Des limites dures dans la plateforme, pas le jugement d'un agent. Trois rollbacks réussis par heure et par cible, un seul rollback en cours à la fois, et quand les passes parallèles ne sont pas d'accord sur la version à restaurer, l'action est bloquée et escaladée vers toi.
A-t-il besoin de mon pipeline de CI ?
Non. Polylane lit les deploys chez les fournisseurs eux-mêmes. La revue de pull requests tourne comme une vérification GitHub que tu peux rendre obligatoire, mais rien ne change dans ton pipeline.
Et les changements qui ne sont pas des deploys ?
Les modifications de config, les événements de scaling et les changements de sécurité sont enregistrés et surveillés de la même façon. Quand une file d'attente se comporte mal douze minutes après que quelqu'un a baissé son visibility timeout, l'enquête part de ce changement.
Puis-je voir pourquoi un rollback a eu lieu ?
Chaque rollback est documenté : le run qui l'a fait, les signaux qui ont régressé, la version restaurée et le raisonnement atterrissent dans l'enregistrement.