What to Prioritize

Your Sentry SDK is sending errors to Sentry Issues out of the box. Now what? This guide covers the high-value error patterns that help you catch problems before they impact users and fix issues faster.

Anatomy of an Error

Sentry automatically captures unhandled errors. For handled errors, use captureException() and add context:

try {
  await processOrder(order);
} catch (error) {
  Sentry.captureException(error, {
    tags: {
      order_id: order.id,
      payment_method: order.paymentMethod,
    },
    level: "error",
  });
  throw error;
}

Levels: fatal, error, warning, info, debug

Context: Tags, user info, logs, and session replays help you debug faster. Tags are searchable, so use them for high-cardinality data like IDs, regions, and feature flags.

Every error in Sentry is automatically trace-connected. Click the trace ID to see the full trace view and understand what led to the error.

Where to Look

Start by creating these five Issue views to catch the most critical problems.

Save these views: Turn these five searches into saved Issues views by clicking Save As after setting each filter.

1. Unresolved High-Volume Issues

High event counts mean either many users are affected or one user is stuck in a loop. Both need immediate attention.

In Issues: Search for is:unresolved (applied by default) and use the sort dropdown (defaults to "Last Seen") to sort by Events

What to look for:

• Issues at the top with high event counts (many occurrences in a short time)
• Click into these issues to see the stack trace and how many users are affected

Learn more about Issue States & Triage to manage and prioritize issues.

Alert idea: Trigger when event count spikes in a short time window to catch high-impact bugs and infinite loops.

2. New Issues After Deploy

Every deploy introduces risk. New errors that appear right after a release are usually regressions.

In Issues: Filter by is:unresolved firstRelease:v1.2.3 to find issues introduced in a specific release. Sort by Age to see the newest issues first.

What to look for:

• Issues that didn't exist in the previous release
• Errors in code paths you just changed
• New error types (TypeError, ReferenceError) indicating breaking changes

Learn more about Release Health to track error rates and crash-free sessions per release.

Alert idea: Trigger when a new issue is created, filtered to production environment and error/fatal level. This catches regressions immediately after deploy.

3. Errors by Environment

Production errors are critical. Staging errors help you catch problems before they reach users. Comparing environments helps you spot configuration issues.

In Issues: Search for is:unresolved environment:production or environment:staging

What to look for:

• Errors only in production (often config, API keys, or data issues)
• Errors only in staging (caught before deploy, needs fixing)
• Same error in both (systemic code issue)

Learn more about configuring environments to separate production and staging issues.

Alert idea: Trigger when a new issue is created, filtered to production environment. These often indicate config drift or environment-specific bugs.

4. Errors with High User Impact

Some errors heavily affect power users. Others affect everyone, but rarely. Prioritize by unique user count, not just event count.

In Issues: Search for is:unresolved and sort by Users to see which issues affect the most unique users.

What to look for:

• Issues affecting many unique users (e.g., more than 10 users indicates widespread impact)
• Issues affecting VIP or paying users (check user tags)
• Issues blocking core workflows (login, checkout, data access)

When you open an issue, the header shows the total number of unique users affected. For more detail, review the user tag distribution to see:

• Unique user identifiers (user ID, email, or IP)
• How many events each user triggered
• Percentage breakdown across users

This tells you if an issue affects many users equally or if one user is stuck in an error loop.

Learn more about custom tags to mark user tiers, plans, or roles. Then search is:unresolved user.tier:enterprise to prioritize high-value users.

Alert idea: Trigger when unique user count exceeds a threshold in a time window (e.g., more than 50 users in 1 hour) to catch widespread issues.

5. User-Reported Issues

When users report problems, they often see an error. User feedback tells you which errors hurt the experience most, even if event counts are low.

Enable the User Feedback Widget to let users report problems directly when errors happen.

In Issues: Navigate to User Feedback in the left sidebar to see reports submitted by users.

What to look for:

• User descriptions of what they were doing when the error occurred
• Patterns in feedback about specific workflows or features
• Issues that frustrate users even if they don't generate many events

Alert idea: Trigger when a new issue is created, filtered to issue category equals feedback. This ensures you respond quickly when users report problems.

Error Handling Strategy

Capture Context, Not Just Exceptions

When you catch an error, add tags and context to make debugging instant. Set user info globally so it applies to all events. Enable Session Replays and Logs for even more visibility.

// Set user globally (e.g., after login)
Sentry.setUser({ id: user.id, email: user.email });

// Add tags and context per-event
Sentry.captureException(error, {
  tags: {
    order_id: order.id,
    payment_gateway: "stripe",
    region: user.region,
  },
  contexts: {
    order: {
      total: order.total,
      items: order.items.length,
      discount_code: order.discountCode,
    },
  },
});

Search in Sentry: order_id:order_123 or payment_gateway:stripe region:us-west

Ignore Known Noise

Some errors aren't actionable. Use ignoreErrors to filter them out.

Sentry.init({
  dsn: "...",
  ignoreErrors: [
    "Non-Error promise rejection captured",
    /^Timeout of \d+ms exceeded$/,
  ],
});

You can also use beforeSend to filter errors dynamically:

Sentry.init({
  beforeSend(event, hint) {
    // Ignore errors from browser extensions
    if (
      event.exception?.values?.[0]?.stacktrace?.frames?.some((frame) =>
        frame.filename?.includes("chrome-extension://"),
      )
    ) {
      return null;
    }
    return event;
  },
});

Quick Reference

Next Steps

Explore the Issues product walkthrough guides to learn more about the Sentry interface and discover additional tips.