Zehn Deploys am Tag. Einer davon ist schlecht. Polylane findet ihn und rollt ihn zurück.
Auf die WartelisteJeder Deploy wird beobachtet, von Haus aus. Was sich geändert hat, wer es geändert hat, und die Signale, die am ehesten brechen.
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 Rollback, wenn du willst. Standardmäßig aus. Schalte es ein, und ein Agent übernimmt den Rest.
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.
Jetzt zurückrollen. Danach richtig beheben. Der Rollback kauft Zeit: Der echte Fix folgt für dein Review.
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.
So funktioniert Polylane. Es lernt dein System, beobachtet es, untersucht und handelt.
-
Es lernt zuerst dein System
Der Context Graph kartiert jede Ressource und Abhängigkeit über deine Clouds, Repos und Observability-Provider. Agenten denken über echte Topologie nach, nicht über Vermutungen.
-
Erkennung ohne Schwellenwerte
Eingebaute Checks für jeden Provider, plus Checks aus deinen eigenen gespeicherten Queries und Dashboards. Ein statistischer Durchgang und ein Agent entscheiden gemeinsam, und eine Verbesserung löst nie ein Issue aus.
-
Untersuchungen mit Belegen
Jede Behauptung verweist zurück auf die Query, die Logzeile oder den Änderungseintrag dahinter. Ein Urteil ohne Belege fällt auf unentschieden zurück.
-
Schreibzugriff wird verdient, nie vorausgesetzt
Konten verbinden sich nur lesend. Rollbacks sind standardmäßig aus, ratenbegrenzt und protokolliert. Codeänderungen gehen durch dein normales Review.
-
Es wird jede Woche schärfer
Memories, tägliche Notizen und Monitoring-Queries, gegen echte Daten neu bestätigt: Die Untersuchung im Juli lernt von der im Juni.
Es steckt sich in das, was du schon betreibst. Nur lesend verbinden und loslegen.
Fragen.
Welche Plattformen kann Polylane zurückrollen?
Deployments auf Cloudflare, Vercel, Render und Fly.io, mit Wiederherstellung des letzten bekannt guten Deploys. Rollbacks sind standardmäßig aus: Du aktivierst sie selbst und kannst sie jederzeit abschalten.
Was verhindert eine automatische Rollback-Schleife?
Harte Limits in der Plattform, nicht das Urteil des Agenten. Drei erfolgreiche Rollbacks pro Stunde pro Ziel, ein Rollback gleichzeitig, und wenn parallele Durchgänge uneins sind, welche Version wiederhergestellt werden soll, wird die Aktion blockiert und an dich eskaliert.
Braucht es meine CI-Pipeline?
Nein. Polylane liest Deploys direkt von den Providern. Das Pull-Request-Review läuft als GitHub-Check, den du zur Pflicht machen kannst, aber an deiner Pipeline ändert sich nichts.
Was ist mit Änderungen, die keine Deploys sind?
Konfigurationsänderungen, Skalierungsereignisse und Sicherheitsänderungen werden genauso festgehalten und beobachtet. Wenn eine Queue zwölf Minuten nach dem Senken ihres Visibility-Timeouts Probleme macht, startet die Untersuchung bei dieser Änderung.
Kann ich sehen, warum ein Rollback passiert ist?
Jeder Rollback ist belegt: Der Run, der ihn gemacht hat, die Signale, die regressiert sind, die wiederhergestellte Version und die Begründung landen im Eintrag.