How do I set up Sentry alerts for a spike in 500s or a new error right after a release?

If you’re seeing a spike in 500s or a brand‑new error right after a release, that’s not the time to go hunting through dashboards. You want Sentry to page you with enough context that you can jump straight to the bad deploy, the failing endpoint, and the suspect commit.

Below is how I normally set this up with teams: first, make sure you’re sending the right data (errors + releases), then wire up alerts that watch for spikes and new issues immediately after a deploy.

Quick Answer: Configure Sentry’s SDK to send errors with release information, then create alert rules that (1) trigger when 500s or error events spike over a baseline, and (2) fire when a new issue appears in a recent release. Route those alerts to your on‑call channels so you can roll back or ship a fix fast.

The Quick Overview

What It Is: A set of Sentry alert rules that watch for 500 status spikes and brand‑new errors tied to your latest release.
Who It Is For: Developers, SREs, and on‑call engineers who own production stability and need to catch breaking releases quickly.
Core Problem Solved: You don’t have to manually check dashboards after every deploy; Sentry alerts you when something actually breaks or regresses.

How It Works

At a high level, you:

Instrument your app so Sentry gets:
- Error events (exceptions, crashes, 500s)
- Release info (release + optionally environment)
- Optional: transactions/spans if you also want performance context
Define alert rules that:
- Watch for spikes in error rate (e.g., 500s, error events per minute)
- Detect first‑seen issues in the newest release
Route alerts into your workflow (email, Slack, PagerDuty, Microsoft Teams, webhook, etc.) so the right owner gets paged.

Under the hood, Sentry:

Groups similar events into issues.
Enriches events with environment, release, and changeset metadata.
Uses alert rules + conditions (e.g., “rate of 500s in the last 5 minutes”) to decide when to notify you.
Links the alert to the issue with stack trace, release, commit, and, if available, Session Replay and traces.

Step 1: Make Sure Releases and Environments Are Configured

To alert “right after a release,” Sentry has to know which release an event came from.

Set the release in the SDK

Example (JavaScript):

Sentry.init({
  dsn: 'https://<key>@o<org>.ingest.sentry.io/<project>',
  release: 'my-app@1.3.0',
  environment: 'production',
});

Example (Python):

import sentry_sdk

sentry_sdk.init(
    dsn="https://<key>@o<org>.ingest.sentry.io/<project>",
    release="my-app@1.3.0",
    environment="production",
)

Use consistent release naming
- Include app name + version (my-app@1.3.0).
- Make sure CI/CD sets this at deploy time, not manually.
Enable releases in your pipeline
- Optional but recommended: use Sentry’s CLI in CI to:
  - Create a release
  - Upload source maps/symbols
  - Associate commits
  - Mark the release as deployed
That’s how you get Suspect Commits and better stack traces in the alert.

Step 2: Capture 500s as Sentry Errors

For web APIs and apps, 500s should show up as Sentry error events. In most server frameworks, the SDK can do this for you.

HTTP‑aware frameworks (Express, Django, Rails, Spring, etc.):
- Make sure Sentry’s middleware is installed.
- Unhandled exceptions that result in 500s will be sent to Sentry.
If your framework swallows errors and just returns 500:
- Either re‑throw the exception so the Sentry middleware can catch it, or
- Explicitly capture:
```
try:
    # your logic
except Exception as e:
    sentry_sdk.capture_exception(e)
    raise
```

Once 500s are flowing as events into your project, you can build alerts on top of them.

Step 3: Create an Alert for a Spike in 500s

You’ll do this in Project Settings → Alerts → Metric Alerts (sometimes labeled “Performance & Errors” depending on UI).

Think of this as: “If 500s/sec crosses this threshold, wake someone up.”

3.1 Choose the dataset and query

Dataset: Errors

Filter / Query: narrow to production 500s, for example:

environment:production http.status_code:500

Or, if you prefer grouping by transaction:

environment:production http.status_code:500 has:transaction

3.2 Select the aggregation

Pick an aggregation that reflects “spike,” for example:

count() of events
count_unique(user) for user‑impact
percentage(count(), total()) if you want error rate vs total requests (when you’re also sending non‑error events / transactions)

A common setup:

Aggregate: count()
Time window: 5 minutes
Condition: Above a threshold

Example: “If more than 50 500s occur in 5 minutes.”

3.3 Configure the rule and thresholds

Set the alert condition:
- When count() of events is > 50 in the last 5 minutes
- Optional: Add a second condition like “and for at least 10 minutes” to avoid flapping.
Add a recovery threshold (optional but useful):
- When count() falls back below 10 in 5 minutes, send a resolve notification.
Set the evaluation interval:
- 1 minute or 5 minutes, depending on how fast you want to know.

3.4 Choose who gets notified

Under Actions:

Select destinations:
- Slack channel (e.g., #prod-alerts)
- PagerDuty service (for paging)
- Email to on‑call group
- Webhook to your own incident system
Customize the alert message:
- Include the environment, top transaction, and a quick hint:
  
  “Spike in 500s in production. Top transaction: {{transaction}}. Release: {{release}}. Check Sentry issue list for new errors in this release.”

Once saved, this alert will fire whenever 500s cross your threshold, which typically means a bad deploy, a dependency outage, or an upstream problem.

Step 4: Alert on New Errors Right After a Release

Now you want the “this didn’t exist before this release” signal.

You can combine two patterns:

Issue Alerts for new issues
Metric Alerts that watch new issues tied to a recent release

4.1 Issue Alert: First‑seen issues in production

Go to Project Settings → Alerts → Issue Alerts → Create Alert Rule.

Use a rule like:

When:
An issue is first seen
If (conditions):
- environment equals production
- Optional: level is error or fatal
- Optional: event.type is error
Then:
- Send to Slack / email / PagerDuty.
- And optionally: Create an issue in your tracker (e.g., Linear, Jira).

This gives you a notification each time a brand‑new issue appears in production. To scope it to post‑release:

Either have your on‑call temporarily watch this channel right after a deploy, or
Add a condition using tags you set on deploy (e.g., release or deploy_window custom tag).

4.2 Metric Alert: New issues by release

If you want a more explicit “this release introduced a bunch of new issues” signal, build a metric alert over issue data:

Dataset: Issues
Filter / Query:
```
environment:production is:unresolved
```
Aggregate:
- count() grouped by release over the last N minutes.
Condition:
- When count() for the newest release is significantly higher than for previous releases.
- Practical approach: set a threshold like “> 10 new issues in 10 minutes” and treat that as “bad deploy.”

In practice:

Aggregate: count()
Time window: 10 minutes
Condition: Above 10

Then choose your alert destinations.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Issue Alerts	Trigger when a new issue is first seen or an issue changes state.	Catch new errors as soon as they appear in production.
Metric Alerts (Errors)	Watch aggregate error counts/rates over time windows.	Detect spikes in 500s or error volume right after a release.
Releases & Suspect Commits	Tie events to releases and commits; identify likely offending changes.	Jump from alert → release → commit → fix without manual triage.
Ownership Rules / Code Owners	Route issues to teams based on file path, service, or tags.	Automatically notify the right team when a release breaks something.
Integrations (Slack, PagerDuty, etc.)	Send alerts into existing on‑call and collaboration tools.	Fit Sentry alerts into your current incident response workflow.

Ideal Use Cases

Best for catching bad deploys fast: Because alerts tied to releases and 500 spikes show you “this deploy broke it” within minutes.
Best for teams with strict SLOs: Because you can turn error spikes into PagerDuty pages and keep downtime within your error budget.
Best for distributed services: Because alerts can be scoped per service or endpoint via tags and transactions, not just “the app is on fire.”

Limitations & Considerations

Too many alerts (noise):
- Start with conservative thresholds (e.g., higher error counts, production‑only).
- Use filters like environment:production and error levels (level:error OR level:fatal).
Too few alerts (blind spots):
- If you almost never get alerts, your thresholds may be too high.
- Use Sentry’s Discover or Issues list to see typical error volume and adjust.
Alerting without ownership:
- If there are no Ownership Rules or Code Owners, alerts land in generic channels.
- Add Ownership Rules so “the team that owns the broken code” gets notified.
Releases not wired up correctly:
- If you don’t set release in the SDK or deploy pipeline, alerts can’t reliably say which release caused the issue.

Pricing & Plans

Alerts themselves are available across Sentry’s plans; what changes by plan is how much data you can push through and how far back you can look:

You configure alert rules per project and they consume from your quotas:
- Error events
- Transactions/spans
- Replays
- Monitors and attachments (if used)
You can:
- Set base quotas and add pay‑as‑you‑go budget for overages.
- Reserve higher volume for discounts (“pay ahead, save money… when you use more, you pay less”).

Example fit:

Developer / Team plans: Best for small teams needing practical alerts on key services, with defined quotas and a handful of dashboards.
Business+ and Enterprise: Best for larger orgs needing SAML + SCIM, organization audit logs, more dashboards, governance, and dedicated customer support (Enterprise) on top of alerts.

For current details, check Sentry’s pricing page, since limits and plan names evolve.

Frequently Asked Questions

How do I avoid false positives when alerting on 500 spikes?

Short Answer: Tune your thresholds and filters based on your normal baseline and only alert on production, high‑severity errors.

Details:
Use Discover or the Issues view to see your average 500s per minute in production. If you typically have 5–10 in a 5‑minute window, setting an alert at > 20 in 5 minutes is more reasonable than > 1. Filter your rule with:

environment:production http.status_code:500 (level:error OR level:fatal)

Add “for at least 5–10 minutes” if you want to avoid short blips from transient upstream issues, and use a recovery threshold so alerts resolve when conditions improve.

Can I target alerts to specific services or endpoints?

Short Answer: Yes. Use tags and transactions to scope alerts to particular services, routes, or queues.

Details:
Sentry SDKs let you tag events with service names, endpoints, or custom keys:

with sentry_sdk.configure_scope() as scope:
    scope.set_tag("service", "payments-api")

Or rely on transaction names (e.g., /api/checkout). Then in your alert query:

environment:production http.status_code:500 service:payments-api

environment:production http.status_code:500 transaction:/api/checkout

This way, only the team that owns that service or endpoint gets paged, and the rest of the org can sleep.

Summary

To catch a spike in 500s or a new error right after a release, you don’t need a sprawling observability rollout. You need Sentry wired to your app’s releases and environments, plus a couple of well‑tuned alert rules:

Metric alerts watching 500 spikes in production.
Issue alerts for first‑seen issues in your latest releases.
Routing via Slack, PagerDuty, or your incident tool with ownership so the right team gets the ping.

From there, you click through the alert into the Sentry issue, see the stack trace, release, suspect commit, traces, and replays, and move straight to a fix instead of guessing.

Next Step

Get Started