Ten deploys a day. One of them is bad. Polylane finds it and rolls it back.
Join the waitlistEvery deploy is watched, out of the box. What changed, who changed it, and the signals most likely to break.
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, if you want it. You say when, in plain English: an agent handles the rest.
When a storefront production deploy goes live, watch error rates and p95 latency for the next 15 minutes. If either regresses against baseline, roll it back and say why.
Done. The trigger fires when a Vercel deploy on storefront reaches ready. Rolling back and opening an incident are smart actions: they only run when the agent judges the run noteworthy. Results go to Slack, quiet runs stay quiet. Anything you want to change before you create it?
Ask anything…
This is a draft of your automation. Click Create above to publish it.
Roll back a bad deploy
Watches storefront production deploys and rolls back the bad ones.
Vercel deploy state ready on main When a production deploy goes live, watch error rates and p95 latency on storefront for the next 15 minutes. If either regresses against baseline, roll the deployment back and say why.
smart: runs only when the agent judged the run noteworthy
#deploys noteworthy runs only · failures always deliver Roll back now. Fix properly after. The rollback buys time: the real fix follows for your 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.
How Polylane works. It learns your system, watches it, investigates, and acts.
-
It learns your system first
The context graph maps every resource and dependency across your clouds, repos, and observability providers. Agents reason over real topology, not guesses.
-
Detection without thresholds
Built-in checks for every provider, plus checks generated from your own saved queries and dashboards. A statistical pass and an agent decide together, and an improvement never raises an issue.
-
Investigations that show receipts
Every claim links back to the query, log line, or change record behind it. A verdict without evidence falls back to inconclusive.
-
Writes are earned, never assumed
Accounts connect read-only. Rollbacks are off by default, rate-limited, and on the record. Code changes go through your normal review.
-
It gets sharper every week
Memories, daily notes, and monitoring queries re-confirmed against real data: July's investigation learns from June's.
It plugs into what you already run. Connect read-only and start.
AWS 
Cloudflare Vercel 
Render 
Fly.io 
Kubernetes 
PlanetScale 
Supabase 
Modal 
GitHub Slack 
Datadog 
Honeycomb 
Axiom 
Sentry 
Better Stack 
Devin 
Cursor 
Factory 
MCP Server Questions.
Which platforms can Polylane roll back?
Cloudflare, Vercel, Render, and Fly.io deployments, restoring the last known-good deploy. Rollbacks are off by default: you enable them per automation and can turn them off at any time.
What stops an automatic rollback loop?
Hard limits in the platform, not agent judgement. Three successful rollbacks per hour per target, one rollback in flight at a time, and when parallel passes disagree on the version to restore, the action is blocked and escalated to you.
Does it need my CI pipeline?
No. Polylane reads deploys from the providers themselves. The pull request review runs as a GitHub check you can require, but nothing about your pipeline changes.
What about changes that aren't deploys?
Config edits, scaling events, and security changes are recorded and watched the same way. When a queue misbehaves twelve minutes after someone lowered its visibility timeout, the investigation starts from that change.
Can I see why a rollback happened?
Every rollback is receipted: the automation run, the signals that regressed, the version restored, and the reasoning land in the record, and results are delivered to Slack, email, or a webhook.