Change intelligence

Most incidents start with a change. Polylane tracks changes on three surfaces: cloud change records, per-resource change history, and pull request reviews.

Cloud change records

Every sync of a connected cloud account produces a change record with:

• Counts of nodes and edges added, modified, and removed in the topology.
• The full list of changed resources and what changed on each.
• A title, a short summary, and a narrative written by an agent.
• An impact level (none, low, moderate, high) and a category (deployment, configuration, scaling, security, networking, data, teardown, discovery, mixed).
• Signals: metrics on the changed resources whose movement would show the change regressed production. Polylane watches them for you.

Deploy and platform events delivered by provider webhooks between syncs are attached to the change record that covers their window, so a change shows up next to the event that caused it.

The first sync of an account produces a discovery record that describes the existing infrastructure instead of a diff.

An agent triages every change record. Most changes pass silently. A change that shows a real, current problem raises an issue, and one confirmed as an incident gets an investigation.

Open a cloud account in the console and use its Changes tab to browse the full timeline.

Per-resource change history

Every resource touched by a change record gets its own change event. This powers:

• A change history on each topology node, so you can answer "what happened to checkout-api this week" without reading whole change records.
• A most-changed-resources ranking in the weekly digest, with each resource's worst impact level over the period.

Pull request change intelligence

Polylane reviews pull requests in connected repositories against the live infrastructure they touch, not against style rules. On every push to an open, non-draft pull request:

1. Polylane waits two minutes for the push burst to settle, then analyzes only the latest head commit.
2. Pull requests that only touch documentation, tests, or continuous integration files pass immediately.
3. It walks the topology from the repository node along deploys_to edges to find the production resources the repository deploys to. A repository that deploys to nothing Polylane knows about passes without an investigation.
4. For each plausibly affected resource it gathers the resource tier, recent change history, and open issues.
5. An agent investigates in a dedicated thread, with the repository cloned at the pull request head, and reaches a verdict.

Polylane keeps one comment per pull request and updates it on each analysis. A pass states that no production concerns were found. A concern flips the comment to a fail with the finding and its impact level, plus links to the investigation thread and the stored analysis. When a later push addresses the concern, the comment flips back to a pass and notes that the concern is addressed. If a concern does not apply, dismiss the analysis in the console: Polylane keeps analyzing new pushes but never comments on that pull request again.

The repository's Changes tab in the console lists every analysis: flagged pull requests first, passed ones collapsed below.

You can also enable the Polylane production impact check run per repository. Concerns fail the check, so branch protection can block the merge; clean verdicts complete it green, with details linking to the investigation. Merge queues are supported: the check completes automatically on merge group commits, since the pull request was already analyzed before it entered the queue.

Automation triggers

Three automation triggers fire on change activity:

• polylane.change_record.created: a new change record exists.
• polylane.infra_node.created: a new resource was discovered. Filterable by provider.
• polylane.cloud_account.synced: a cloud account finished syncing. Filterable by provider.

{
  "type": "polylane.infra_node.created",
  "filters": { "providers": ["aws"] }
}

How agents use changes

Agents check changes first. Investigations start from recent changes: deployments, configuration changes, and infrastructure modifications in the last 24 to 48 hours, assessed for overlap with the reported symptoms. In any thread, the searchChangeRecords tool lists and searches change records by account, time range, and natural-language query, so you can ask an agent "what changed in production in the last hour" and get cited change records back.

Try it from your coding agent:

Use Polylane to list everything that changed across my infrastructure in the last 24 hours and flag any changes that correlate with open issues.