Detect

Issues

Every problem Polylane detects or receives from your alerting becomes one issue, worked by one fix run whose thread tells the whole story.

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

SourceDescription
Polylane checksChecks on connected resources and cloud accounts evaluate metrics, logs and traces, and record an issue when one finds a real problem.
Provider alertsAlerts from connected observability tools and cloud accounts become issues, so everything that might need attention runs through one lifecycle. See Integrations.
Opened from a threadHand a problem off in a chat thread and the agent opens the issue for you, which starts its fix run.

How it works

  1. 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.
  2. 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) or dismissed (noise or expected behavior). A finding that belongs to an issue already open, or one resolved recently, joins that issue instead.
  3. 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, low or info, and the run can regrade it once it has read the evidence.
  4. 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

StatusDescription
newRecorded, no fix run yet.
triagingThe fix run is reading the evidence and has not reached a verdict.
confirmedA real problem. Shown as an incident; the run works it to a fix unless it is held for a person.
dismissedNot a problem. Kept so the same signal folds quietly next time.
skippedNo fix run started, for example because the signature is suppressed in workspace settings.
failedThe 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.

  • 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.