Error groups

Error groups keep repeated failures from becoming a noisy list of individual events. When Errorgap receives similar errors from a project, it groups them so your team can understand the underlying failure once and track how often it happens.

What is an error group?

An error group represents one underlying failure pattern. It has a message, error type, stack trace, first seen time, last seen time, occurrence count, state, and related context. Teams use the group as the shared place to investigate, assign, mute, resolve, or reopen work.

Open an error group when you need to see the latest occurrence, inspect the backtrace, check affected environments, or understand whether the failure changed after a release.

Occurrences

An occurrence is one captured instance of an error. A group can have one occurrence or many. Occurrences help you understand frequency, recency, affected environments, and whether an issue is still active.

• First seen shows when Errorgap first observed this failure pattern.
• Last seen shows the most recent occurrence in the group.
• Occurrence count shows how many times the grouped failure was captured.
• Environment helps separate customer-impacting failures from staging or development noise.

Grouping signals

Errorgap uses information from the reported error and its stack trace to decide when events likely share the same root cause. Useful signals include error type, message shape, code location, stack frames, and project context.

Grouping is designed to reduce noise while keeping distinct failures visible. If a group looks too broad or too narrow, use the review tools in the error detail view to decide whether related groups should be merged or separated.

Group state

Group state tells the team what should happen next. Keep states current so dashboards, alerts, and teammates reflect the real status of the work.

• Unresolved groups need review or action.
• Muted groups are known noise or intentionally ignored for now.
• Resolved groups are believed to be fixed.
• Regressed groups were resolved but appeared again.

Metadata and context

Error group metadata helps explain impact and root cause. Review it before opening a ticket or assigning the issue.

• Error type and message show what failed.
• Stack trace and source context show where the failure happened.
• Environment and release values show where and when it happened.
• Request or runtime context can identify affected paths, jobs, users, or inputs.
• Activity and timeline details show recent state changes and related work.

Merge and split review

Sometimes two groups represent the same failure, or one group contains events that should be tracked separately. Errorgap surfaces similar groups to help you review those cases.

Merge groups when they share the same root cause and should be triaged together. Split or keep groups separate when the failures have different owners, fixes, or customer impact.

Triage workflow

1. Open the project error list and filter to the environment you care about.
2. Sort or scan by recency, occurrence count, and state.
3. Open the group and confirm the message, stack trace, release, and context.
4. Assign an owner or open a linked issue when the failure needs work.
5. Mute known noise or resolve groups after the fix is shipped.
6. Watch for regressions after future releases.