Error tracking
Failed requests grouped into issues you can assign and close.
Where errors come from #
Errors are derived from your traces. A span is an error when its status says so, or when a server span returned a 5xx status.
Issues #
An event is one failure. An issue is a group of events with the same same shape: the same error type, a matching message and a matching stack.
Values that change between occurrences — identifiers, numbers, paths — are normalised away before grouping, so one failure produces one issue instead of one issue per request.
- Service — where the failure occurred.
- Error type and message — what went wrong.
- Stack — where in the code it happened.
- First and last seen — how long it has been happening.
- Event count — how much it is affecting users.
Issue states #
- For review — newly grouped and awaiting a decision.
- Reviewed — looked at, not yet resolved.
- Ignored — known and acceptable.
- Resolved — fixed.
Assign an issue to a member, set its state, or both. Resolving an issue records the moment, so a later occurrence reopens it as a regression rather than disappearing.
Filters #
Narrow the issue list by:
- service
- error.type
- owner
- assignee
- state
- Sources — narrow to browser, mobile or backend errors.
- Fix available — issues with a known remedy attached.
- Teams — issues owned by a team.
- Assigned to — issues assigned to a member.
Triage workflow #
- Filter to For review to see what is new.
- Assign each to an owner so the work has a destination.
- Move reviewed issues to Resolved once fixed.
- Ignore the ones you have consciously accepted.
Start with the issues having the highest event count. Fixing one that fires a thousand times an hour is worth more than five that fire once.
Onward #
An issue is a summary; the requests behind it are in Searching traces filtered to errors. To be told about it rather than to go looking, set an Error tracking monitor.
Limits #
- Up to 5,000 error events are considered for a window.
- A triage request may name up to 500 issues.