> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tester.army/llms.txt
> Use this file to discover all available pages before exploring further.

# Track Issues

> Track bugs found by QA runs in one deduplicated list per project - with occurrence counts, environment scoping, triage, and Linear or Jira export.

The project **Issues** tab collects the bugs your runs find. Each bug appears once, no matter how many runs hit it, so you triage a list of problems instead of a list of failed runs.

## How issues are created

When a run finishes, TesterArmy records its findings as project issues:

| Source       | When it is created                                                                                                                                                                           |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Bug report   | The agent judged the product to be misbehaving and reported it, with expected vs actual behavior and reproduction steps.                                                                     |
| Step failure | A failed run returned no bug report, but a product-related step failed. The row carries a **Step failure** badge. Treat it as a lead: confirm it as a real bug, or mark it a false positive. |

Non-blocking warnings, such as [accessibility audit](/run/accessibility-audit) findings, stay on the run report and are not added to the Issues tab.

## Deduplication and occurrences

Repeat sightings of the same bug fold into one issue instead of creating new rows. TesterArmy matches reports on the bug name and page, and also folds reports that describe the same bug in different words on the same page. Step failures match on the step and the test, so the same step title failing in two different tests stays two issues.

Every fold adds an occurrence. The issue page lists them under **Occurrences**, with each run's status, environment, trigger, duration, and start time, and shows the most recent evidence under **Latest occurrence**.

## Environments

Issues are bound to the environment of the run that found them. The same bug on Production and on Staging is tracked as two separate issues.

By default the list shows **Live environments**, which excludes PR previews: preview failures are reviewed in the [pull request flow](/run/pull-request-testing). Open preview issues that are not seen again for 7 days are resolved automatically. Switch to **All environments** or a single environment to see them.

## Statuses

| Status             | Meaning                                                                                      |
| ------------------ | -------------------------------------------------------------------------------------------- |
| **Open**           | Needs attention.                                                                             |
| **Resolved**       | Fixed. If a later run surfaces the same bug again, it reopens automatically as a regression. |
| **False positive** | Not a real bug. It stays muted, never reopens, and future matching reports are rejected.     |

Change a status from a row's actions menu (**Mark as resolved**, **Mark as false positive**, **Reopen**), or from the issue page with **Mark resolved** and its overflow menu. Use **Mark as duplicate** on an open row to resolve it as a duplicate. **Delete** on the issue page removes the issue entirely.

To triage many issues at once, select rows with their checkboxes and use the bar at the bottom of the screen. Up to 100 issues can be selected at a time.

## Filter and sort

| Control     | Options                                                             |
| ----------- | ------------------------------------------------------------------- |
| Search      | Matches the issue name or description                               |
| Status      | **Open**, **Resolved**, **False positives**                         |
| Environment | **Live environments**, **All environments**, or one environment     |
| Sort        | **Last seen**, **First seen**, **Severity**, **Occurrences**        |
| Date        | **All dates**, **Last 24 hours**, **Last 7 days**, **Last 30 days** |

Filters are kept in the page URL, so you can reload or share a filtered view.

## Export to Linear or Jira

Open an issue and click **Create ticket** to export it to a connected tracker. When both [Linear](/integrations/linear) and [Jira](/integrations/jira) are connected, or neither is, **Create ticket** opens a menu to pick the tracker. Rows also offer **Create Linear ticket** and **Create Jira ticket** in their actions menu.

After export, the issue links to its ticket (for example `ENG-42`) instead of offering a new export.

## Fix with a coding agent

On the issue page, **Copy prompt to fix** copies a debugging prompt built from the issue's evidence. Use the menu next to it to open the prompt directly in Cursor, Claude Code, or Codex.

## Read issues from the API and MCP

Issues are available read-only to automation. Triage and ticket export stay in the dashboard.

| Surface | List                                      | Detail                                              |
| ------- | ----------------------------------------- | --------------------------------------------------- |
| API     | `GET /api/v1/projects/{projectId}/issues` | `GET /api/v1/projects/{projectId}/issues/{issueId}` |
| MCP     | `list_project_issues`                     | `get_project_issue`                                 |

Both list surfaces accept `status` (`open`, `resolved`, `false_positive`), `environment` (`production`, `staging`, `preview`, `custom`), and `limit` (1-100, default 50). The detail includes reproduction steps, expected vs actual behavior, severity, occurrence count, the linked ticket, and recent run occurrences. See the [API Reference](/api-reference) and [MCP server](/cli/mcp).