Triage errors

Triage is the process of turning a stream of error groups into clear decisions. A good triage pass identifies customer-impacting failures, assigns ownership, suppresses known noise, and keeps the project dashboard accurate.

Triage goals

The goal is not to fix every error during the first review. The goal is to decide what each error group needs next and make that decision visible to the team.

• Find new or regressed production failures quickly.
• Separate actionable failures from known noise.
• Assign an owner when investigation or a code fix is needed.
• Link follow-up work to the issue tracker your team uses.
• Keep muted and resolved states current.

Review the error list

Start from the project error list. Use filters to focus on the environment and group states that matter for the current review. For most teams, the first pass should focus on unresolved and regressed production groups.

1. Open the project that owns the application or service.
2. Filter to the relevant environment, usually production for customer-impacting work.
3. Review unresolved and regressed groups first.
4. Scan last seen time and occurrence count to understand frequency and recency.
5. Search by error type, message, route, job, or release when investigating a known issue.

Open a group

Open a group when the list view suggests the error may need action. Confirm the details before assigning or changing state.

• Message and type show the failure your team is reviewing.
• Stack trace shows the code path that produced the error.
• Environment and release show where the error happened and what version was running.
• Context can reveal affected routes, jobs, inputs, or user-visible flows.
• Activity shows recent state changes, linked work, and team actions.

Decide the next action

Each reviewed group should leave triage with a clear next action. If the impact is unclear, assign investigation rather than leaving the group untouched.

• Investigate when the cause or impact is not yet clear.
• Fix when the group points to a real defect with an owner.
• Monitor when the signal is new but too low-volume to act on immediately.
• Mute when the group is expected, unactionable, or intentionally ignored.
• Resolve when the fix has shipped or the condition no longer applies.

Assign and link work

Assign the group to the person or team responsible for the next step. When the work belongs in another tool, create or link an issue so implementation and triage stay connected.

Include enough context for the assignee to start: the error message, affected environment, recent release, suspected code path, and any customer impact you can infer from the group.

Mute, resolve, or reopen

Group state should reflect the team decision. Keeping state current makes future triage faster and prevents stale issues from hiding real regressions.

• Mute groups that are known and intentionally ignored. Add enough context so future reviewers understand why.
• Resolve groups after the fix ships or after the team confirms the failure no longer needs action.
• Reopen or treat as regressed when the failure returns after being resolved.

Triage habits

Small habits keep the error list useful as the project grows.

• Review production unresolved groups regularly.
• Prefer explicit owners over vague follow-up.
• Use comments or linked issues to record why a group was muted or resolved.
• Watch regressed groups after releases.
• Keep project access and notification paths aligned with current ownership.

When a group needs more evidence, move from the error detail to logs, performance data, infrastructure signals, uptime monitors, or session replay depending on what the failure suggests.