Reading exceptions
The Exceptions page groups stack traces by fingerprint — two crashes with the same shape collapse into one row, with an occurrence count and timestamps.
Why grouping
If a single bug causes a hundred thousand stack traces, you don't want a hundred thousand rows. Grouping reduces that to one entry showing the trend.
The fingerprint is computed from the exception type + the top frames of the stack. Different exception types or different top frames are different groups.
Header
- Title:
Exceptions · Auto-detected errors and exceptions grouped by fingerprint. - Refresh button top-right.
- Source switcher in the left rail scopes the page.
Time picker
Presets: 15m | 1h | 6h | 24h | 7d plus explicit From/To datetime inputs.
Filter tabs
Five lifecycle filters across the top:
- All — every fingerprint group, regardless of state.
- Unresolved (default) — actively firing groups.
- Investigating — someone has acknowledged and is looking.
- Resolved — manually marked done. Will start a fresh group if it occurs again.
- Ignored — muted. Does not count toward dashboards or alerts.
Sort by
Dropdown top-right. Options include Last Seen (default), occurrence count, first seen, etc.
Results table
Per-row columns:
| Column | Means |
|---|---|
| (checkbox) | Bulk-select for batch actions. |
| TYPE / MESSAGE | Exception class + brief message (e.g., NullPointerException at PaymentService.charge:142). |
| COUNT | Occurrences in the time range. |
| FIRST SEEN | When this fingerprint was first seen — ever, not just in the time range. |
| LAST SEEN | Most recent occurrence. |
| SERVICES | Service names that produced this fingerprint. |
| ACTIONS | Per-row icons (mark investigating, resolve, ignore). |
| STATUS | Current lifecycle state pill. |
When no fingerprints match the filter:
> "No exceptions found for this filter"
Detail view
Click a row to open the fingerprint detail (separate page). Shows the full stack trace with most-recent-first ordering, occurrence chart over time, sample log line that produced the exception, tags from the originating log (service, environment, version, user_id when present), and any alert rules firing on this fingerprint.
Actions
Each fingerprint can be:
- Mark Investigating — moves to the Investigating tab; useful for "I'm looking into this".
- Resolve — moves to Resolved. New occurrences after resolve open a fresh group.
- Ignore — moves to Ignored. Stops counting toward dashboards or alerts. Use for known-noisy errors you can't fix immediately.
Bulk-select multiple rows with the checkboxes to apply the same action to all.
What this is not
- Not log search. It's specifically structured exception/stack data. Use Log Explorer for free-text log search.
- Not bug tracking. Resolving here doesn't close a Jira issue. Wire up a webhook channel to push to your tracker.