Triage issues in Bugsink

There is rarely time to investigate every error as it arrives, so use search, event counts, and trends to choose what to look at first, then resolve or mute each issue as you review it.

In Bugsink, an event records one occurrence of an error. Repeated occurrences are grouped into issues, with counts, trends, history, and state kept at the issue level. A new event can turn a resolved issue into a regression.

If repeated events are being split into separate issues, start with the grouping documentation. Split issues also have separate counts, trends, and state histories.

Start with the issue list

The top-level Issues page shows issues from every project you can access. A project’s own issue list covers only that project and adds search.

Both lists have the same state views:

• Open contains issues that are neither resolved nor muted. This is the default working queue.
• Unresolved also includes muted issues. Use it when you want every problem that has not been marked as fixed.
• Muted contains issues you have deliberately taken out of the Open queue.
• Resolved contains issues marked as fixed, while All removes the state filter.

You can order a list by Last seen or Most events. Last seen puts current activity first; Most events puts the highest lifetime event counts first. Neither is a severity ranking. A payment failure that occurred once may matter more than a harmless timeout that occurred a thousand times.

Each row shows when the issue was first and last seen, its friendly ID, its lifetime event count, and a compact trend. The friendly ID, such as BACKEND-42, is useful when discussing an issue in a commit, ticket, or chat.

Read the trends

The compact sparkline on each issue row shows the last 24 hours, split into one-hour buckets. The lifetime count shows total volume; the sparkline shows when events arrived during the last day.

For example:

• A spike at the right edge means the issue has become active recently.
• A steady row of bars points to a recurring background problem.
• A flat line followed by activity often lines up with a deployment or an external change.
• No recent bars with a large lifetime count describes an old or intermittent issue.

Each sparkline has its own scale, so compare the shape of two sparklines, not their bar heights. Use the numeric event count to compare volume between issues. Hovering a bucket shows its actual count.

The Event Details tab for an issue contains a larger, 28-day chart. Depending on the available screen width, it uses 24-, 12-, or 6-hour buckets. The red marker shows the event currently on screen, and clicking a bar jumps to an event from that time bucket.

The charts are backed by hourly count buckets. Bugsink does not need to rescan the event table every time an issue or project list is opened, and the chart can still represent events whose full payload has since been removed by the retention process.

Search for the relevant issues

On a project’s issue list, a plain-text query searches the exception type and value. A structured query uses exact key:value filters. You can combine the two:

• TimeoutError finds that text in an exception type or value.
• environment:production handled:false requires both tag values.
• release:2.6.0 TimeoutError combines a tag filter with plain text.
• user.email:developer@example.org finds errors associated with one user.
• url:"https://example.org/checkout" finds errors reported for that request URL.

Use double quotes when a value contains spaces. Colons and escaped quotes are supported inside values, so complete URLs work as expected.

The url tag contains the request URL without its query string or fragment. These URLs therefore match the same page:

  

  

  Copy
https://example.org/checkout?coupon=SAVE#payment
https://example.org/checkout?coupon=OTHER
https://example.org/checkout?coupon=SAVE#payment
https://example.org/checkout?coupon=OTHER

Search both with:

  

  

  Copy
url:"https://example.org/checkout"
url:"https://example.org/checkout"

URL tags are created for newly ingested events. After upgrading an older installation, run bugsink-manage init_tags if you want to derive current tags, including URLs, from retained events that were already in the database.

Bugsink also deduces searchable tags for releases, environments, servers, transactions, users, browsers, operating systems, handled state, and trace IDs. Applications can add their own tags through the SDK. The complete built-in list is in Deduced Tags.

Search within an issue

Opening a result carries the query into the issue view. The search box on the Stacktrace, Event Details, Breadcrumbs, and Event List pages then moves through only the events that match.

An issue can contain thousands of occurrences with different context. To narrow those events further:

1. Search the issue list for environment:production to find affected issues.
2. Open an issue and add user.email:developer@example.org or a request URL.
3. Move between the matching events while comparing their stacktraces, local variables, request data, and breadcrumbs.

On the Event Details chart, a search adds an overlay: the background bars show all events and the darker bars show the retained events that match the query. Clicking a bar keeps the filter and jumps to a matching event in that bucket.

Total trend counts come from the hourly buckets. Search, including the overlay, uses retained event and tag rows. If older payloads have been evicted, the overlay can contain fewer events than Bugsink originally received.

Inspect the events

After selecting an issue, use its stacktrace and event context to investigate the failure:

• Stacktrace shows the call stack, source context, and captured local variables.
• Event Details contains request, runtime, user, and custom context.
• Tags shows how occurrences are distributed across releases, environments, users, browsers, and custom tags.
• Event List shows the retained occurrences, with search available for narrowing the list.
• History records resolving, muting, unmuting, reopening, and regressions.

For example, the tag breakdown may show that 95% of occurrences come from one release, browser, or server.

Resolve or mute

Use Resolve for an issue that has been fixed and Mute for an issue you do not plan to act on.

Resolve means that you believe the problem is fixed. With releases configured, Bugsink provides three choices:

• Resolve marks it fixed without tying the decision to a release. Any later occurrence is a regression.
• Resolved in next release allows events from the current release while the fix is waiting to be deployed.
• Resolved in latest records the fix against the latest release Bugsink has observed.

A resolved issue can be reopened manually. It is also reopened automatically as a regression when an event arrives in a release where the issue should have been fixed.

Mute means that the issue is known but should not be in the active queue. Muting hides it from Open and suppresses its alerts without discarding its events or history. You can mute:

• indefinitely;
• for a fixed period, such as one day or one week; or
• until its volume crosses a threshold, such as 100 events in 24 hours.

A timed mute ends when the next event arrives after the deadline. A volume-based mute ends when an event crosses the configured threshold. In either case Bugsink marks the issue as unmuted and can alert on that state change. You can also unmute it manually.

The same actions work in bulk from the issue list. Select several issues and resolve, mute, or unmute them together. Release-specific resolution remains project-scoped, because a cross-project selection does not share one release.

Deleting removes the events and the state history Bugsink would need to recognize a future regression. See Deleting issues for the cases where this is appropriate.