The ticket becomes a pull request. Polylane does the digging in between.
Join the waitlistIt checks what changed first. Half the tickets trace back to a change somebody made.
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 Theories get tested, not trusted. Confirmed only with evidence from your real systems.
Hyperdrive pool exhaustion after deploy 9f3c2a1
Confidence: strong · 3 of 3 passes
Upstream PlanetScale degradation
Confidence: definitive · 3 of 3 passes
Cold-start regression in the new isolate
Confidence: weak · 2 of 3 passes
The fix arrives ready to review. Root cause, validation, and the diff included.
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.
How do I hand Polylane a ticket?
Start a thread in the console, over the CLI, or from your editor through the MCP server, and describe the bug. Agents take it from there with the workspace's full context: the graph, the telemetry, the change records, and the code.
What if it can't find the cause?
It says so. Investigations end resolved, diagnosed, or inconclusive: an investigation that couldn't reach data never confirms, and anything that needs a human decision becomes one escalation, not a nagging loop.
Does it learn from past tickets?
Yes. Confirmed findings are stored as memories and retrieved by meaning in later threads, and daily notes keep a running record of what happened. July's investigation learns from June's.
Who writes the fix?
Polylane's autofix by default: investigated first, written, and validated, with the reasoning attached. Or hand the implementation to Devin, Cursor, or Factory. Either way, you review it.
Which repositories does it work with?
GitHub repositories, connected through the GitHub app. The fix lands on a branch in the repo behind the affected service, with the investigation linked from the change.