Docs/Triage & diagnostics
#

Triage & diagnostics

When a test run finishes with multiple failures, you don't want to investigate each one cold. Cofactor's triage groups related failures by likely root cause and attaches per-failure diagnostics, so you start from causes instead of symptoms.

01How triage works

After a test run completes, Cofactor runs triage over its failures:

  1. It collects a diagnostic for each failed workflow run — an analysis of why that run failed.
  2. It clusters failures that likely share a root cause.
  3. It ranks the clusters by severity and surfaces the most pressing one first.

You'll find this in the Triage tab on a completed test run.

02Run diagnostics

Open a failed workflow run and start its diagnostic investigation. Cofactor runs the investigation in an isolated browser workspace, so the diagnostic can inspect the failure without affecting your active browser work.

The diagnostic can inspect the live browser session while investigating the failure. Use this inspection to verify the current page, visible state, and interaction result instead of relying only on the run recording.

03Inspect live browser evidence

Open the diagnostic investigation for a failed run, then inspect the live browser session at the point of failure. Use the browser view to check the page state and confirm what the workflow encountered.

Capture the evidence that supports the investigation, such as:

  • Screenshots of the relevant page or error state
  • Videos showing the interaction and failure
  • Traces that show the sequence of actions and resulting behavior

Keep evidence focused on the failure. Attach the relevant captures to the finding or issue so another person can verify the result without repeating the investigation.

04Reading the clusters

Each cluster represents one likely root cause and carries a title, a severity, the number of failures it covers, a summary, and a suggested next action. Start with the highest-ranked cluster, read its summary, then open the workflow runs grouped under it to confirm the cause before moving on.

Clusters also mark failures that are new — failing for the first time — so you can separate fresh regressions from ongoing breakage.

05Review findings

Review the diagnostic on the failed workflow run alongside its steps, assertions, recording, and captured evidence. Diagnostics now return discrete findings, so you can review each observed problem separately rather than treating the investigation as one undifferentiated summary.

Open a finding to read its explanation, inspect its supporting screenshots, videos, or traces, and compare it with the workflow's expected behavior. Recent runs also show a diagnostic category, which helps you identify the type of failure and compare related investigations.

Use the findings, diagnostic summary, and category to decide whether the failure needs a code or configuration fix, another investigation, or an issue for tracking.

06Triage states

While triage is preparing, the tab shows its progress:

StateWhat it means
Waiting on diagnosticsCofactor is still collecting the per-failure analyses triage needs.
RunningCofactor is analyzing failures and building clusters.
SkippedTriage didn't run for this test run (for example, no failures to cluster).
FailedTriage couldn't complete. Investigate failures manually from the workflow list.

If triage is Skipped or Failed, fall back to the workflow list and the per-run failure investigation flow.

07Per-failure diagnostics

A failure diagnostic is the analysis behind a single failed workflow run — produced asynchronously, then attached to the run and to any issue occurrence it generated. Open a failed workflow run to read its diagnostic alongside the steps, assertions, and recording. Triage clusters are built from these diagnostics, so the cluster tells you the shared cause while each diagnostic explains an individual failure.

08File and review issues

If a finding shows that a failure warrants tracking, file an issue directly from the diagnostic results or attach the diagnostic to an existing issue. Use an issue when the failure represents a defect or recurring problem that needs follow-up; don't create one for an expected or already-understood failure.

When you file or attach an issue, review and edit the plain-language summary, expected behavior, and reproduction steps. Include the screenshots, videos, traces, and other supporting evidence that substantiate the finding before submitting it.

After filing, review the issue in the existing issue drawer or from the diagnostic report view. Confirm that the finding, reproduction details, and evidence are attached, then use the issue's normal workflow to assign and track follow-up.