Monitoring
Issues
A thousand errors from one bad deploy is one problem, not a thousand. Monitoring groups errors into issues so the list reflects what's actually broken.
What an issue is
Errors that share a cause collapse into a single issue with a count and a first-seen and last-seen time. You triage the issue, not each occurrence.
Grouping
Errors are grouped by the top frames of the stack that belong to your code, and each issue shows the culprit those frames point at. Your dependencies are ignored for grouping, which is what stops every unrelated failure inside your HTTP client collapsing into one meaningless issue.
Users affected
Each issue shows how many distinct users hit it. It's the number that should decide priority: 10,000 errors from one customer's retry loop matters less than 200 errors across 200 customers.
The count is only as good as what your app reports. If your SDK calls don't carry a user identity, every issue shows the same story and this column can't help you.
Regression detection
Resolve an issue and it stays resolved only as long as it doesn't come back. If it recurs, it reopens automatically, marked as a regression, and can fire an alert.
Marking an issue resolved says "this shouldn't happen again". Monitoring holds you to it: if it recurs, the issue comes back rather than quietly incrementing a count on something everyone stopped looking at.
Triage
Each issue carries a state, so the list stays a work queue rather than an archive.
- Look at it
Open the issue. You get the grouped occurrences, the stack trace, and the facets below.
- Set a state
Triage it so the next person doesn't re-investigate what you already dismissed.
- Discuss it in place
Comments live on the issue. The context stays with the error rather than in a thread nobody can find later.
Facets
Facets break an issue down by attribute: release, environment, endpoint, and so on. They answer the question that decides everything else, which is "who is this actually happening to?"
10,000 errors reads like an outage. Faceted by release, 9,900 of them on the canary you rolled back an hour ago reads like a resolved incident with a 100-error tail worth looking at.
Suspect commits
For an issue with resolved symbols, Octri maps the failing frames back to the commits that last touched those lines and surfaces the most likely culprits.
It works from resolved frames. Minified frames point at a.b.c, which never touched any commit. If this section is empty, symbols are missing or the release ids don't match. See Symbolication.
Reading a stack trace
With symbols uploaded, frames resolve to real files and lines, and the dashboard shows the code at each frame.
Go, Rust, and JVM stacks already carry file and line. The source shown next to each frame is the source tree you uploaded with sources upload. Without it, you get the frame but not the code.
From an issue to a trace
An issue tells you what broke. A trace tells you what the request was doing when it broke. Jump between them rather than guessing.