Catch issues before they reach production. Every pull request reviewed against what's live, not just the diff.
Join the waitlistThe warning lands before the merge. The mechanism, the evidence, and the fix: right where you review.
Add trigram index for order search #482
main from order-search-trgm 
Merging this pull request may degrade production (high impact).
Merging this blocks every write to orders while the index builds. migrations/0114_order_search_trgm.sql:3 adds CREATE INDEX … USING gin (search_text gin_trgm_ops) without CONCURRENTLY, and a plain CREATE INDEX takes a full write lock on orders for the whole build. Checkout sustains ~38 writes/s on that table; each one queues behind the lock until the build finishes.
To make this safe: build the index with CREATE INDEX CONCURRENTLY outside the transactional migration.
Polylane analysed de91b47 for production impact.
It improves the code, not just gates it. Missing instrumentation gets added right on your branch.
Key queries
31 active · 2 telemetry gapsGenerated from your telemetry and your connected code, judged on observed data: every candidate ran against a day of real data before it was kept.
And it keeps watching after the merge. Whatever slips through gets caught in production.
Critical latency degradation in checkout-edge 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 ··· 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 does AI pull request review work?
Polylane connects to GitHub as an app and reviews each pull request against the live infrastructure it deploys to: the context graph, current telemetry, and recent changes. The verdict lands as a comment plus a 'Polylane production impact' check.
Will it block my merges?
Only if you want it to. Require the 'Polylane production impact' check through branch protection and risky merges are blocked; leave it optional and the verdict is advisory.
Is this for AI-generated code?
It's for all code. It just matters most when nobody read the change closely: the safety net for AI-generated code is the same review that catches the hand-written mistake.
How is this different from CI?
CI runs your tests against the code. Polylane reviews the change against production: the config, capacity, and dependencies it lands on, and the telemetry they emit right now. It shows up as a check in the same list, answering a different question.
Will it ever merge or deploy on its own?
No. Changes reach your default branch only through your review, and rollbacks to a previous known-good deploy stay off until you enable them.