Get started Dashboard

Catch issues before they reach production. Polylane reads each pull request against the infrastructure it lands on.

Polylane catches the pull request that would break production, before it merges.

Get started for free

The warning lands before the merge. It comments where you review, with the evidence attached.

github.com/coreplane/orders-api/pull/482

Add trigram index for order search #482

Open rvidal wants to merge 1 commit into main from order-search-trgm
Conversation 1 Commits 1 Checks 2 Files changed 1
polylane bot commented 2 minutes ago ···
Caution

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.

orders-db · writes per second · last 48h
0 20 40
-48h -24h now
every one of these writes blocks while the index builds

Polylane analysed de91b47 for production impact.

Some checks were not successful 1 failing and 1 successful check
ci / test Successful in 2m 4s Details
Polylane production impact Non-concurrent index build locks writes on orders Details
Merging is blocked

It adds the logging you forgot. Right on your branch, matching your existing setup.

Observability improvements for #218 polylane +22 −2
Requests do not produce one context-rich event 3 affected routes · found after the last sync
server/api/checkout.post.ts mirrors your existing OpenTelemetry setup; no new dependencies
export default defineEventHandler(async (event) => {
const body = await readBody(event);
- const order = await createOrder(body);
- return { orderId: order.id };
+ return tracer.startActiveSpan("checkout", async (span) => {
+ const canonical: Record<string, unknown> = {
+ route: "checkout",
+ requestId: event.context.requestId,
+ cartId: body.cartId,
+ traceId: span.spanContext().traceId,
+ };
+ try {
+ const order = await createOrder(body);
+ span.setAttributes({ "order.id": order.id, "order.amount_cents": order.amountCents });
+ Object.assign(canonical, { orderId: order.id, amountCents: order.amountCents, outcome: "ok" });
+ return { orderId: order.id };
+ } catch (err) {
+ span.recordException(err);
+ span.setStatus({ code: SpanStatusCode.ERROR });
+ canonical.outcome = "error";
+ throw err;
+ } finally {
+ span.end();
+ emitCanonicalLogLine(canonical);
+ }
+ });
});
Opened against the pull request's own branch, as a small change that can merge first.

The watching doesn't stop at the merge. Whatever slips through gets caught in production.

Topology
Search your cloud resources...
Galaxy
checkout-edge Worker
Critical Critical to your architecture.

Issue hotspot: 4 issues in the last 7 days

Change hotspot: 12 changes in the last 7 days

Cloudflare · coreplane · earth · Compute
hd-prod Hyperdrive
Critical Critical to your architecture.

Change hotspot: 7 changes in the last 7 days

Cloudflare · coreplane · earth · Databases
ingest-events Lambda function
Standard Important to your architecture.

Issue hotspot: 2 issues in the last 7 days

AWS · coreplane-prod · us-east-1 · Compute
payments-db Database
Critical Critical to your architecture.

Issue hotspot: 1 issue in the last 7 days

Change hotspot: 3 changes in the last 7 days

PlanetScale · coreplane · us-east · Databases
Investigate

checkout-edge

Worker · Production · Synced 2 minutes ago
Cloud GraphProblems
10 problems on this resource, newest first
  • Critical latency degradation in checkout-edge worker
  • checkout-edge P99 latency above 2s for 5m
  • Subrequest count climbing against its weekly baseline
  • CPU time p99 above baseline after deploy 4a91c7e
  • Cache hit ratio dipped during the analytics backfill
  • Error rate on /checkout/session above baseline
  • Durable Object storage reads doubled overnight
  • Subrequest timeout to payments-api, single occurrence
  • Fix run stopped on a sandbox clone failure
  • Wall time p99 regression traced to the analytics backfill
2 detections have not been investigated on their own.

Peace of mind. Nothing happens behind your back.

Agents should act on your behalf without putting production at risk. Polylane is built so you can leave it alone.

Read-only from the start

Every account connects read-only: AWS through a scoped role, most providers with an API token. Write access is a separate, per-account decision.

Agent
AWS Cloudflare
query metrics delete stack read logs purge cache

Writes are earned

A write pauses the run and shows you the exact call before anything happens, unless you allowed it ahead of time. Nothing reaches production just because an agent decided it should.

write request

PATCH /workers/checkout-edge

reason: restore the Hyperdrive pool to 50

Approve Reject with a note
waiting on you Cloudflare

Evidence for everything

Every claim links to the query, log line or deploy behind it. Every run is a transcript you can watch, interrupt and share.

thread transcript

● queryLogs → 4,112 rows cited

● deployHistory → 12 deploys cited

cause: deploy 9f3c2a1 evidence

These prompts already work. Copy one, swap your own service name in, and run it.

Give it to your coding agent and let it cook.

“Review PR #241 against production: what does it deploy to, and what breaks if it merges?” “If checkout-api goes down, what goes down with it? Walk the graph and rank by traffic.” “We're renaming the orders table tonight. Which services, queries, and crons touch it?” “List every deploy since Friday and flag the ones whose metrics moved afterwards.” “Write release notes for this week's deploys, including what regressed and what got fixed.” “Which services are closest to their limits: connection pools, queues, compute?”
Every prompt

Swap the agent. Keep everything.

Your connections, context graph and memories live with Polylane, not with the agent. When a better coding agent ships, point it at the same MCP server and everything comes along.

  • Connections and scopes live in the workspace: connect once, every agent benefits
  • Works with Claude Code, Cursor, Codex, OpenCode, VS Code, Pi, and whatever ships next
  • Memories, notes and investigations persist: switching agents loses nothing
Claude Code Cursor Codex OpenCode VS Code Pi
Claude CodeCursorCodexOpenCodeVS CodePi
aws cloudflare datadog github slack sentry

Polylane runs the whole loop. You step in when it needs you.

  • It learns your system first

    The context graph connects every resource and dependency across your clouds, repos and observability providers, so Polylane reasons over your real system instead of guessing.

  • Detection without thresholds

    Built-in checks for every provider, plus checks built from your own saved queries and dashboards. Statistics and an agent decide together, and a metric getting better never raises an issue.

  • Investigations that cite their sources

    Every claim links back to the query, log line or deploy behind it. Without evidence, the verdict is inconclusive.

  • Writes are earned, never assumed

    Accounts connect read-only. Write actions pause for your approval, with the request and reason on screen, unless you've allowed it ahead of time. Code changes go through your normal review.

  • It gets sharper every week

    It remembers what it confirms, keeps daily notes, and re-checks its monitoring queries against real data, so every incident makes the next one faster.

It plugs into what you already run. Connect read-only and start.

AWS Cloudflare Vercel Render Fly.io Kubernetes PlanetScale Supabase Modal Railway Convex GitHub Slack Linear Datadog Honeycomb Axiom Grafana Cloud Sentry Devin Cursor Factory MCP Server Every integration

Common questions.

How does AI pull request review work?

A GitHub app reviews each pull request against the live infrastructure it deploys to. 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, but it matters most when nobody read the change closely. AI-written or hand-written, the same review catches the 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 what they emit right now.

Will it ever merge or deploy on its own?

Not by default. Every change goes through your review, and anything that merges or touches production on its own is something you switch on.

More use cases
Incident response DevOps Ticket resolution

Your agents ship fast. Polylane keeps up. Every change gets read against production before it merges.

Get started for free