Issues

An issue is the single record of a problem: something Polylane's own monitoring detected, or an alert a connected provider sent. Every detection flows through the same lifecycle: detected, triaged, investigated, resolved.

Where issues come from

• Agent checks: monitoring agents evaluate metrics, logs, and traces on connected resources and cloud accounts, and record an issue when a check finds a real problem. Threshold checks you configure raise issues the same way.
• Change evaluation: change intelligence assesses every infrastructure change. A change judged risky becomes an issue linked to the change record.
• Provider alerts: alerts forwarded from Datadog, Honeycomb, Sentry, Amazon CloudWatch, Vercel, Axiom, Render, and Cloudflare become issues, so everything that might need attention lives on one surface.

Issues can also be opened deliberately: an automation runs the openIssue action, or you hand a problem off from a chat thread and the agent opens the issue for you. Both start the issue's investigation as well.

Severity

Issues carry one of five severities: critical, high, medium, low, or info. Provider severities are normalized on ingest: a provider critical stays critical, error maps to high, warning maps to medium, and everything else maps to info. Triage can raise the severity when it confirms an incident, and you can edit it by hand.

Deduplication

Every issue carries a fingerprint built from its source identity: the resource and check for Polylane detections, the integration and external alert id for provider alerts.

• A new firing that matches an active issue increments that issue's occurrence count instead of creating a duplicate.
• A firing that matches an issue resolved within the last 24 hours reopens it and bumps the occurrence count.
• When a provider rotates alert ids for the same underlying problem, Polylane folds the new alert into the existing issue by matching source, integration, and title.

Each occurrence lands on the issue timeline, including how long the issue was quiet before it fired again. A reopened issue keeps its investigation: the re-fire nudges the same investigation instead of starting a second one.

Triage

Issues from Polylane's own checks arrive already triaged: the detecting agent only records real problems. Issues from provider alerts are triaged by an agent that fetches the raw payload, the source query behind the alert, and recent metrics around the firing before deciding. Triage lands on one of two verdicts:

• Incident: the issue is a confirmed problem that needs response. Polylane starts an investigation on the issue.
• No incident: noise, expected behavior, or a duplicate of something already tracked.

An incident is a verdict, not a separate record. There is no second list to manage: the issue carries its verdict, its investigation, and its timeline. Verdicts are never limited, so every confirmed issue is visibly an incident on every plan.

You can turn triage off per alert rule or for a whole connection. Issues from a muted rule still record and deduplicate, but skip triage.

Investigation

When triage confirms an incident, Polylane starts an investigation: one coordinating agent engagement embedded in the issue. The conversation lives in the issue's Investigation tab, and the agent spawns hypothesis sub-agents that each test one possible cause in parallel.

Auto-investigation limits

Workspaces cap how many investigations start automatically in a rolling 24 hours. On the Free plan the cap is 1 per day. Paid plans set their own cap, or none, under Settings, Investigations, which also shows current usage. Past the cap, the issue keeps its incident verdict, is marked Investigation held, and shows a Start investigation button. Workspace admins are emailed, and an admin can start the investigation manually at any time. Manual starts never count against the cap. See Investigations for the details.

Viewing issues

Issues live at /issues in the console. Each issue has six tabs:

• Overview: title, summary, severity, status, verdict, contributing metric cards, and an Investigate button when no investigation has started yet.
• Metrics: the time series that contributed, each with current value, baseline, and the underlying query.
• Logs: log volume by severity plus the top and newly appeared log templates around the firing.
• Traces: a trace digest with exemplars, when the source provides them.
• Timeline: everything that happened, described below.
• Properties: the full issue record, including resource identifiers, tags, fingerprint, and occurrence count.

An Investigation tab appears once an investigation exists. It holds the investigation conversation: the coordinating agent, its hypotheses, and their verdicts.

Timeline

The issue timeline carries the full history: detection, re-detections, the triage verdict, investigation started or held, hypothesis results, every escalation raised against the issue, every autofix milestone from branch push to pull request merge, and resolution. You can add your own notes and milestones to it.

Resolution

Issues resolve themselves when the underlying problem recovers:

• A recovery from the provider resolves an alert issue.
• Polylane-detected issues resolve when a later check cycle comes back clean and every monitored series is back within its long-horizon baseline. If a series still deviates, resolution is withheld.

Resolving an issue closes its investigation. You can also resolve an issue by hand if the platform misjudged it. If the same problem returns within 24 hours, the existing issue reopens instead of creating a new one, and its investigation takes a fresh look.

From the API

# List active high-severity issues in a workspace
curl "https://api.polylane.com/v1/issues/<workspace-id>?severity=high&active=true" \
  -H "Authorization: Bearer <api-key>"

# Get a single issue
curl "https://api.polylane.com/v1/issues/<workspace-id>/<issue-id>" \
  -H "Authorization: Bearer <api-key>"

Reading issues requires the issues:read API key scope. Resolving or editing them requires issues:write.

Try it from your coding agent:

Use Polylane to list the open issues in my workspace, pick the most severe one, and summarize what is known so far with citations to the metrics and logs behind it.

Related

• Investigations for what happens after an issue is confirmed as an incident.
• Change intelligence for the change evaluation that raises change issues.
• Automations for the polylane.issue.triaged trigger.
• Clouds for the resources issues are scoped to.