Issues
An issue is the single record of a problem: something Polylane's own checks found, or an alert a connected tool sent. The record keeps score (fingerprint, occurrences, verdict, severity); the fix run thread that works it is where you read what happened.
What it does
Every detection runs through one lifecycle, whatever its source: it is recorded, a fix run reaches a verdict, a confirmed incident is worked to a fix, and the issue resolves when the problem is over. There is no raw alert queue to triage by hand. Duplicates fold into the issue that already exists, so one problem is one record and one thread.
Where issues come from
| Source | Description |
|---|---|
| Polylane checks | Checks on connected resources and cloud accounts evaluate metrics, logs and traces, and record an issue when one finds a real problem. |
| Provider alerts | Alerts from connected observability tools and cloud accounts become issues, so everything that might need attention runs through one lifecycle. See Integrations. |
| Opened from a thread | Hand a problem off in a chat thread and the agent opens the issue for you, which starts its fix run. |
How it works
- A finding is recorded with a fingerprint built from its source: the resource and check for Polylane detections, the integration and alert id for provider alerts. A firing that matches an open issue increments its occurrence count instead of creating a duplicate.
- A fix run reads the raw payload, the query behind the alert, recent metrics and your code, then records one of two verdicts:
confirmed(a real problem) ordismissed(noise or expected behavior). A finding that belongs to an issue already open, or one resolved recently, joins that issue instead. - A confirmed issue is worked to a fix in the same thread, unless the workspace's severity floor or plan limit holds it for a person to start. Severity is one of
critical,high,medium,loworinfo, and the run can regrade it once it has read the evidence. - The issue resolves when the problem is over: a recovery from the provider, a later check that comes back clean, or an alert that stays quiet. You can also mark one Resolved yourself. If the same problem returns within 24 hours (longer for issues that name a code defect), the existing issue reopens and its fix run takes a fresh look.
Statuses
| Status | Description |
|---|---|
new | Recorded, no fix run yet. |
triaging | The fix run is reading the evidence and has not reached a verdict. |
confirmed | A real problem. Shown as an incident; the run works it to a fix unless it is held for a person. |
dismissed | Not a problem. Kept so the same signal folds quietly next time. |
skipped | No fix run started, for example because the signature is suppressed in workspace settings. |
failed | The run never reached a verdict. |
An issue also carries resolvedAt once the problem is over, whichever status it holds.
Where to find it
Open Issues in the console to browse detections, filter by severity or status, and find active or held issues. Each issue has a page with its evidence, investigation, timeline and properties. Use Investigate to start a run, or Open thread to continue the conversation. The API's _html_url field links directly to this page, including for issues without a run.
Under Threads, the Fix runs preset lists the agent conversations. The run's last message is its outcome: a pull request, no fix needed, or something that needs you. The thread's sidebar opens the evidence and any escalation, with Open full page to view the record.
Every cloud account, integration and topology resource has a Problems tab listing the fix runs on that scope. An issue that never got a run appears as a card in the feed; expand it and use Investigate to start one. From scripts, the issue is a first-class object in the API reference, read with the issues:read scope and edited with issues:write.
Related
- Fix runs for how a run reaches its verdict and works a confirmed issue.
- Threads for reading a transcript and its evidence.
- Escalations for what happens when the agent needs you.
- Clouds for the accounts and resources issues are scoped to.
Detect
Polylane reads your telemetry and raises issues, reviews every pull request against production, and flags risky configuration, with no alert rules to write.
Pull request reviews
Every pull request in a connected repository is checked against the production it deploys to, and you hear about it before you merge.