English for Sentry Error Tracking

Triaging production errors in Sentry involves a specific vocabulary — “issue” doesn’t mean the same thing as “error event,” and “fingerprint” isn’t a security term here. Teams that use these words loosely end up with confusing bug tickets and duplicate investigations. This guide covers the terms you need to talk about Sentry clearly with your team.

Key Vocabulary

Issue — a group of similar error events that Sentry has clustered together based on a shared fingerprint, representing one underlying problem rather than a single occurrence. “This issue has 400 events, but they’re all the same underlying null reference — it’s one bug, not four hundred.”

Fingerprint — the value Sentry uses to decide which events belong to the same issue, derived by default from the stack trace but customizable. “These two errors have different messages but the same fingerprint, so Sentry correctly grouped them into a single issue.”

Breadcrumb — a trail of events (clicks, navigation, API calls) leading up to an error, captured automatically to help reconstruct what the user was doing. “The breadcrumbs show the user submitted the form twice within a second — that’s what triggered the duplicate request error.”

Release — a tagged deployment (usually a git SHA or version string) that Sentry associates with events, letting you see which deploy introduced or fixed an issue. “This issue started appearing right after release v2.4.1 shipped — let’s check what changed in that diff.”

Regression — an issue that Sentry had marked as resolved but that reappeared in a later release, automatically reopened and flagged for attention. “Sentry flagged this as a regression because it was resolved in the last release but just came back in today’s deploy.”

Source map — a file mapping minified production code back to original source, required for Sentry to show readable stack traces instead of minified gibberish. “The stack trace was useless until we uploaded the source maps — now it points straight to the actual line in the TypeScript file.”

Common Phrases

• “Is this a new issue, or did it just regress after the last release?”
• “The fingerprint is grouping unrelated errors together — we should add a custom fingerbrint rule.”
• “Check the breadcrumbs before assuming it’s a backend issue — this might be a client-side race condition.”
• “Are the source maps actually uploaded for this release? The stack trace looks minified.”
• “How many users are affected by this issue, not just how many events?”

Example Sentences

Triaging an issue in a stand-up: “This issue spiked right after yesterday’s release, affects about two percent of sessions, and the breadcrumbs all show it happening right after a specific API call times out — I think it’s a regression from the retry logic change.”

Reporting a grouping problem: “Sentry is lumping three genuinely different bugs into one issue because they share a fingerprint from a generic error message — can we add a custom fingerprinting rule to split them apart?”

Explaining severity to a manager: “It’s technically a new issue, but the event count is misleading — it’s a single user retrying the same failed action forty times, not forty different users affected.”

Professional Tips

• Say “issue” when referring to the grouped problem and “event” when referring to a single occurrence — conflating them makes severity assessments inaccurate.
• When an issue reappears, use the specific word “regression” rather than “it’s back” — it signals the issue was previously resolved and ties directly to a release.
• Always check breadcrumbs before writing a root-cause hypothesis in a bug report — they often reveal the actual trigger sequence.
• Mention whether source maps are correctly uploaded when a stack trace looks unreadable — it’s a common and easily overlooked cause of unclear reports.

Practice Exercise

1. Explain in two sentences the difference between an issue and an event in Sentry.
2. Write a one-sentence report describing an issue that reappeared after being marked resolved.
3. Describe, in your own words, why source maps matter for reading a production stack trace.