Read an incident
What each part of the incident view means, and what to do with it.
Open Issues and select one. The page is arranged in the order you should read it: what happened, what it means, and what you can do.
The parts of the page
| Section | What it tells you |
|---|---|
| Summary | A plain-language description of the failure |
| Root cause | What the model believes started it, and why |
| Risk level and score | How urgent this is — calculated by rules, not by the model alone |
| Business impact | Who is affected and how, in non-technical terms |
| Affected areas | The parts of the system implicated |
| Developer notes | Detail written for whoever picks up the work |
| Suggested fixes | One or more proposed changes, each with an explanation |
| Event detail | The raw stack trace and request context, with sensitive fields removed |
How much to trust it
The analysis is a starting point, not a verdict. Two habits keep it useful:
- Read the root cause against the event detail below it. If the trace does not support the story, the story is wrong.
- Treat the risk score as the priority signal and the narrative as the explanation. They are produced separately on purpose.
Closing the loop
Every incident can be moved to one of three states:
| State | Use it when |
|---|---|
| Acknowledged | Someone has seen it and owns it |
| Resolved | The cause is fixed and you expect it to stop |
| Ignored | It is known, accepted, and should stop asking for attention |
Ignoring an issue does not stop it being collected — it stops it competing for attention. The history stays.