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

# Triage issues

> Read, explain, resolve, ignore, and reopen grouped LogBrew issues from the CLI.

Issues are grouped failures. LogBrew uses stable fingerprints so repeated
occurrences of the same error become one issue with a count.

## Status values

| Status       | Meaning                                 |
| ------------ | --------------------------------------- |
| `unresolved` | Needs attention.                        |
| `resolved`   | Fixed or no longer active.              |
| `ignored`    | Intentionally muted from active triage. |

## Recommended workflow

<Steps>
  <Step title="List unresolved issues">
    ```bash theme={null}
    logbrew read issues --status unresolved --environment production --json
    ```
  </Step>

  <Step title="Read the issue detail">
    ```bash theme={null}
    logbrew read issue <issue_id> --json
    ```
  </Step>

  <Step title="Follow related traces and logs">
    ```bash theme={null}
    logbrew read trace <trace_id> --json
    logbrew read logs --trace <trace_id> --json
    ```
  </Step>

  <Step title="Explain the failure">
    ```bash theme={null}
    logbrew explain issue <issue_id> --json
    ```
  </Step>

  <Step title="Update status">
    ```bash theme={null}
    logbrew set issue <issue_id> resolved --json
    logbrew set issue <issue_id> ignored --json
    logbrew set issue <issue_id> unresolved --json
    ```
  </Step>
</Steps>

## What makes a good issue

* Clear title.
* Human-readable message.
* Stable fingerprint.
* Stack frames when available.
* Release, environment, service, and trace context.
* Attributes with the smallest useful context, not entire payload dumps.

<Note>
  Agents should not mark an issue resolved until they have read the issue,
  checked related telemetry, and verified the code or deployment fix.
</Note>