How do I get alerted when a brand-new exception starts happening in production (not just volume spikes)?

Most teams already get paged when an error volume spikes. The harder problem is getting alerted the moment a brand-new exception shows up in production—before it snowballs into a spike. That’s exactly what Sentry’s issue-based alerts and “new issue” conditions are built for.

Quick Answer: In Sentry, you get alerted on a brand-new exception by creating an alert on new issues (not just event counts), scoping it to your production environment, and routing it to the right channel. Sentry groups stack traces into issues, so that alert only fires when Sentry sees a pattern it’s never seen before.

---

The Quick Overview

• What It Is: An issue-based alerting workflow in Sentry that notifies you when a new exception pattern is first observed in production, instead of waiting for a volume threshold.
• Who It Is For: Developers, SREs, and on-call engineers who want to catch regressions, edge cases, and “first occurrence” bugs as soon as they hit real users.
• Core Problem Solved: Traditional alerts trigger on high error rates; by the time you notice a brand-new exception, it’s often already hurting users. New-issue alerts give you an early warning the instant a new production error appears.

---

How It Works

Sentry doesn’t just count raw log lines. It groups similar events (exceptions) into issues based on stack trace, error type, and other attributes. A “brand-new exception” in Sentry terms is a new issue: a unique error fingerprint Sentry has never seen in that project before.

You use that grouping to your advantage:

1. Group exceptions into issues:
   Sentry SDKs send exceptions from your app to Sentry. Sentry groups them into issues, with context like release, environment, tags, and suspect commits.

2. Define an alert for “new issues”:
   In the Alerts page for your project, you create an alert rule that fires when a new issue is created, optionally limited to a specific environment (e.g., environment:production) or release.

3. Route the alert to your team’s workflow:
   Send alerts to email, Slack, Microsoft Teams, PagerDuty, or your issue tracker. Ownership Rules and Code Owners can route new issues straight to the right team, so the alert doesn’t just page “everyone.”

From there, your team uses Sentry’s error detail page, stack trace, tags, Session Replay (if enabled), and related transaction spans to quickly decide: is this a one-off edge case, or the start of a real incident?

---

Step-by-Step: Alert on Brand-New Exceptions in Production

1. Make sure you’re sending production errors to Sentry

First, confirm your Sentry SDK is:

• Installed in your application.
• Configured with:
  • environment=production (or equivalent).
  • Releases (so you can tie new issues back to deploys).
• Capturing unhandled exceptions.

Once events are flowing, you should see issues in your project that are tagged with environment:production.

2. Use issue alerts (not metric alerts) for new exceptions

Sentry has two main alert types:

• Issue alerts: Trigger based on issues (e.g., “a new issue is created” or “an issue’s event volume crosses a threshold”).
• Metric alerts: Trigger based on time-series metrics (e.g., error rate, transaction throughput, Apdex).

You want issue alerts for “brand-new exception” behavior because the unit is “new issue,” not raw volume.

In Sentry:

1. Go to Alerts → Rules in your project.
2. Click Create Alert → Issues.

3. Set the condition to “New issue”

Configure your alert rule:

• Conditions:

  • Add: “A new issue is created”
    This tells Sentry to fire the alert the first time a new error fingerprint appears.

• Filter by environment:

  • Add a condition or filter: environment equals production
    This ensures dev/staging experiments don’t wake up your on-call rotation.

You can add additional filters as needed:

• Filter by level: only trigger on error and fatal, ignore warning.
• Filter by tag: e.g., only issues from service:checkout or tenant:enterprise.

4. Route the alert to the right place

Under Actions:

• Choose where to send alerts:
  • Slack (common for “new issue in production” alerts).
  • Email to an on-call list.
  • PagerDuty or another incident system for high-severity errors.
  • Issue creation in tools like Jira or Linear (automatic ticket).

To keep noise under control, consider:

• Using Ownership Rules/Code Owners so new issues are auto-assigned to the right team.
• Using different channels for different severity levels (e.g., Slack for most new issues, PagerDuty only when they match specific tags or endpoints).

5. Cut noise with smarter conditions

Not every brand-new exception deserves a page.

You can combine the “new issue” trigger with volume or user impact to keep things signal-heavy, not noisy:

• Condition: A new issue is created
• AND: The issue is seen more than N times in Y minutes
  Example: “the issue is seen more than 5 times in 10 minutes.”
• AND: Optional tag filters (url:/checkout, release:2024.10.1).

This hybrid approach gives you what you asked for—alerts on new exceptions—but only once they show early signs of being real problems, not one-off bot traffic.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Issue Grouping	Groups exceptions into unique issues based on stack trace and context.	Treats “brand-new exception” as a new issue fingerprint, not just a log line.
Issue Alert Rules	Lets you trigger alerts on “new issue created” plus filters and thresholds.	Alerts you the moment a new error appears in production, before it spikes.
Ownership Rules & Integrations	Routes alerts to specific teams via Slack, email, PagerDuty, Jira, Linear.	Gets the alert to the people who can actually fix it, automatically.

---

Ideal Use Cases

• Best for catching regressions right after deploys:
  Because Sentry can tie issues to releases and suspect commits, “new issue in production” alerts become a deploy early-warning system. You see new exceptions introduced by a release before they become a full incident.

• Best for discovering rare, high-impact edge cases:
  Because you’re not waiting for volume spikes, you can spot a single new exception that indicates a serious bug (e.g., security-related, data loss) even if only a handful of users hit it.

---

Limitations & Considerations

• New-issue alerts can be noisy if you ship fast:
  If your team deploys frequently and introduces many new code paths, you could see a lot of new-issue alerts. Use filters (environment, level, tags) and volume conditions (“seen more than 5 times in 10 minutes”) to keep noise manageable.

• Not a replacement for health-based error rate alerts:
  New-issue alerts won’t catch a known error that suddenly spikes in frequency. Keep separate metric alerts or issue alerts for volume spikes to handle those scenarios.

---

Pricing & Plans

Sentry’s ability to alert on new issues is available across plans; what changes by plan is how far you can scale and how much governance you get:

• You can:
  • Send errors/exceptions with SDKs.
  • Group them into issues.
  • Create issue alerts on “new issue created.”
  • Integrate with tools like Slack, email, and issue trackers.

Quotas and limits are set per plan (errors, spans, replays, attachments, monitors), with the option to:

• Add pay-as-you-go budget for overages.
• Reserve volume for discounts (“pay ahead, save money… when you use more, you pay less”).

Plan fit

• Developer / Team: Best for small to mid-sized teams needing straightforward “new exception in production” alerts, CI/CD-driven deploys, and basic on-call routing via Slack/email.
• Business / Enterprise: Best for larger orgs needing advanced governance (SAML + SCIM), multiple teams, more dashboards, and enterprise-grade support around incident workflows and compliance.

For exact pricing, limits, and what’s included on each tier, check the pricing page from the main site.

---

Frequently Asked Questions

Can I alert only when a new exception happens in production, not in dev or staging?

Short Answer: Yes. Filter your new-issue alert rule by environment so it only fires for environment:production.

Details:
When you configure the alert rule, add an environment condition:

• Use the environment dropdown in the alert builder, or
• Add a filter such as environment:production.

This ensures that:

• Errors in dev, QA, or staging don’t trigger your production on-call alerts.
• You can optionally create separate “new issue in staging” alerts with a lower-severity channel (e.g., a dev-only Slack channel) if you still want to keep an eye on those.

---

How is “brand-new exception” defined—what if the message changes but the stack trace is similar?

Short Answer: Sentry uses fingerprinting (stack trace, error type, and other context) to group events into issues. A “new issue” alert fires only when Sentry sees a fingerprint it hasn’t seen before in that project.

Details:
By default, Sentry groups events by:

• Exception type (e.g., TypeError, NullReferenceException).
• Stack trace frames (file names, functions, line numbers).
• Occasionally other attributes.

If the exception message changes but the underlying stack trace is essentially the same, Sentry typically groups it into the same issue, and you will not get another “new issue” alert. That’s intentional—you don’t want a new alert every time the text changes.

If you need more control:

• Use custom fingerprints in your SDK to force grouping behavior.
• Add tags (e.g., tenant, feature_flag) so you can filter new-issue alerts only for certain segments.

---

Summary

To get alerted when a brand-new exception starts happening in production—not just when your error volume spikes—you should:

• Use Sentry’s issue alerts, not just metric alerts.
• Trigger on “a new issue is created” and scope it to environment:production.
• Add filters and minimal volume conditions to avoid noise.
• Route alerts using Ownership Rules and integrations so they land with the right team, in the right channel.

This gives you an early, code-level signal the first time a new error appears in production, with the full stack trace, release, and environment context you need to fix it quickly.

---

Next Step

Get Started