Errors and Orbit bugs

Pulse turns errors into groups and connects each group to an Orbit work item, so that one problem produces one bug. This page explains how grouping works, how an error moves through its lifecycle, and how the link to Orbit behaves.

Where errors come from

Pulse creates an error event at intake from:

an error span with an exception event or an error.type;
an error-level log (error, critical, alert or emergency) that carries a stack trace (for example error.stack, exception.stacktrace or stack_trace), an error type (error.type, exception.type, error.kind), an error or err attribute, or a recognisable stack trace in its message (Java, Python, Go panics, ClickHouse);
JavaScript errors from real user monitoring, which land in the same groups.

Within one trace, the same error on several spans of one service counts as one event.

How errors are grouped

Events are grouped by a fingerprint:

By default: the service, the error type and the top five application frames, without line numbers. Library and runtime frames are skipped, and paths keep their last two segments. Frames are understood for Java/Kotlin, .NET, Node.js, Python, Ruby, PHP and Go.
Without frames: the message, with numbers, ids, UUIDs, IP addresses, URLs, e-mails, quoted values and times replaced by placeholders.

Because line numbers and ids are ignored, a redeploy that moves code around does not split a group.

Custom fingerprint rules

A project administrator can add rules (up to 100 per project). The first enabled rule whose query matches an event replaces the default fingerprint with its template, which can use {{service}}, {{env}}, {{version}}, {{resource}}, {{error.type}}, {{error.message}} (normalised) and {{default}}. Rules apply to new events only.

Merge and unmerge

Select up to 20 groups and merge them into a target. The sources become merged, and a source’s Orbit link moves to the target if the target has none. You can send merged-in fingerprints back with unmerge.

Each group shows first and last seen, event counts, affected versions and environments, sample stack traces (with library frames folded), and an activity log.

Lifecycle

Status	Meaning
`open`	New or active
`acknowledged`	Someone is looking at it
`resolved`	Fixed. Optionally resolved in a version.
`ignored`	Hidden, optionally until a time (a snooze)
`merged`	Merged into another group

A resolved group regresses to open when an event arrives after the resolution. A group resolved in a version only regresses on events from that version or later (semantic versions; other version strings when they differ).
An ignored group reopens when its snooze ends.
Project members and administrators change the status; viewers can read.

Create an Orbit bug

From a group, choose Create Orbit bug, or link the group to an existing work item by its key. Pulse never writes Orbit records itself. It records a durable request, and Orbit’s own bridge carries it out through Orbit’s normal create path as the person who asked, with that person’s current permissions. As a result:

the bug follows the project’s work types, priorities and workflow;
the reporter is a person, not a shared integration account;
the bug carries the stack trace, counts and versions;
if the person lacks permission, or the work type is not in the project’s scheme, the request fails without retry and the group shows why. Other failures retry with backoff.

Only one bug request can be pending per group, and a group can be linked to one work item.

Two-way sync

In Orbit	In Pulse
The linked work item moves to the done category	An open or acknowledged group becomes `resolved`
The work item is reopened	A resolved group reopens
The work item is deleted	The group is unlinked
	A regression of a linked group comments on the work item
	A linked group that keeps happening adds at most one digest comment a day

The sync from Orbit runs about every 15 seconds. Unlinking a group from Pulse leaves the work item unchanged.

The Observability panel in a work item

An Orbit work item shows an Observability panel with the error groups linked to it: title, status, service, first and last seen, events in the last 24 hours and in total, versions and regressions. It opens the group in Pulse.

Monitors file bugs too

A monitor with automatic bug creation files one Orbit bug per monitor and group, as the monitor’s owner. It adds a comment when the group alerts again, recovers, or is still alerting at a reminder. Once that bug is done, the next alert files a new one. See Monitors and alerts.

Suspect commits

When Forge deployments are known to Pulse, a new or regressed error lists the suspect commits: the commits between the previous and the current deployed commit, with their merge requests and linked Orbit work. Stack frames also open the file in Forge at the commit that ran, using your Forge permissions.