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
Octri gives each event a fingerprint, and events with the same one form an issue.
| The event has | Grouped by |
|---|---|
| A stack trace | The top frames that belong to your code, as function@file:line. Your dependencies are ignored, and the issue shows the culprit those frames point at |
| No stack trace | Its level, error name, method, path and message |
Variable parts such as IDs, UUIDs, numbers and quoted values are taken out first, so User 123 not found and User 456 not found are one issue.
To group events yourself, set a fingerprint on the event.
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 has a status, so the list stays a work queue rather than an archive.
| Status | Meaning | If it happens again |
|---|---|---|
| Unresolved | Needs attention | Keeps counting |
| Resolved | Shouldn't happen again | Reopens as a regression |
| Ignored | You've decided it doesn't matter | Stays out of your way |
Open an issue to work on it:
| Control | What it does |
|---|---|
| Assignee | Says who's on it |
| Snooze | Hides it for 1 hour, 24 hours or 7 days, or until 10 more events or 100 more events |
| Tags | Your own labels, for finding related issues |
| Comment | Keeps the context with the error, rather than in a thread nobody can find later |
| Activity | The history of what's been done |
From the CLI, see issue commands.
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.