Sentry in 10 Minutes: Catch Every Production Error Automatically

Series: Production Ready — Part 2 of 30

The App That Nobody Was Watching

Let me tell you about a launch I watched implode in real time.

A dev team spent three months building a mobile app. Backend in NestJS, looked clean. Unit tests passing. Deployed to production on a Tuesday morning. Within 15 minutes of real users signing up, random errors were surfacing, the app was freezing, and crashes were cascading across the system. The team had no idea — not because the errors weren't happening, but because nobody had set up error monitoring.

They were flying completely blind.

When they finally dug into the logs by hand, they found the iOS app was firing seven or eight API requests simultaneously on startup, before a user was even logged in. The signup API and user profile API were running in parallel, and a 300-millisecond replication delay between their primary database and read replica meant user profile queries were returning stale data. Signup failures. Cascade. Chaos. The entire story went viral on Reddit and was covered by the Economic Times.

The kicker? Every one of those errors was detectable the moment the first user signed up. With Sentry in place, the on-call engineer would have had a Slack notification with a full stack trace within seconds. Instead, they found out from angry users.

That's the silent failure problem. Your production app is throwing errors right now that you don't know about. Silent errors are not just embarrassing — they are a slow business risk. A January 2026 analysis by CIO.inc describes how silent technology failures distort portfolio decisions, delay corrective action, and entrench technical debt. And according to MEV's 2025 downtime cost research, 90% of firms report an hour of downtime costs them over $300,000.

You can prevent the silent failure problem in under 10 minutes. That's what today is about.

What Sentry Actually Is

Sentry is not just a log aggregator. It is an application monitoring platform that automatically captures runtime exceptions, groups them intelligently, attaches full stack traces with environment context, and alerts your team in real time.

When your app throws an unhandled exception:

The Sentry SDK intercepts it
Sentry attaches the stack trace, request details, user context, environment, and the specific commit that introduced the error
The event is sent to your Sentry dashboard
Similar errors are grouped so you're not drowning in duplicates
An alert fires to Slack, email, PagerDuty — wherever your team lives

Zero manual logging required. Once the SDK is installed, it watches everything automatically.

As of early 2026, Sentry has also launched Seer, an AI debugging agent that performs root cause analysis in the background and can even propose code fixes — but that's a bonus. Today we are getting the foundation in place.

Step 1: Create Your Sentry Account and Project

Go to sentry.io and sign up. The free tier gives you 5,000 errors/month — more than enough to start.

Once logged in:

Click Create Project
Choose your platform (Python, JavaScript, Next.js, etc.)
Sentry gives you a DSN (Data Source Name) — that's your connection string

Keep that DSN handy. You'll use it in every install.

Step 2: Install the SDK

Python (FastAPI, Flask, Django)

pip install --upgrade sentry-sdk

For FastAPI:

import sentry_sdk
from sentry_sdk.integrations.fastapi import FastApiIntegration
from sentry_sdk.integrations.starlette import StarletteIntegration

sentry_sdk.init(
    dsn="https://YOUR_KEY@oXXXXXX.ingest.sentry.io/XXXXXXX",
    integrations=[
        StarletteIntegration(transaction_style="endpoint"),
        FastApiIntegration(transaction_style="endpoint"),
    ],
    traces_sample_rate=1.0,   # Capture 100% of transactions for now
    environment="production",
    release="my-app@1.0.0",   # Tag errors to specific releases
)

That's it for FastAPI. Every unhandled exception is now automatically captured.

For Django, add to settings.py:

import sentry_sdk

sentry_sdk.init(
    dsn="https://YOUR_KEY@oXXXXXX.ingest.sentry.io/XXXXXXX",
    integrations=[
        sentry_sdk.integrations.django.DjangoIntegration(),
    ],
    traces_sample_rate=0.2,  # 20% in prod to manage volume
    send_default_pii=True,   # Include user context
    environment="production",
)

JavaScript / TypeScript (Node.js, Express)

npm install @sentry/node

import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: "https://YOUR_KEY@oXXXXXX.ingest.sentry.io/XXXXXXX",
  environment: process.env.NODE_ENV,
  release: process.env.RELEASE_VERSION,
  tracesSampleRate: 0.2,
});

// For Express — must be first middleware
const app = express();
Sentry.setupExpressErrorHandler(app);

Next.js

npx @sentry/wizard@latest -i nextjs

The wizard handles everything — sentry.client.config.ts, sentry.server.config.ts, source map uploads. Takes about 2 minutes.

React (browser errors)

npm install @sentry/react

import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: "https://YOUR_KEY@oXXXXXX.ingest.sentry.io/XXXXXXX",
  environment: "production",
  integrations: [
    Sentry.browserTracingIntegration(),
    Sentry.replayIntegration(), // Session replay on errors
  ],
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0, // Always replay on error
});

Step 3: Verify It Works

Don't just assume it works. Test it deliberately.

# Python — trigger a test error
sentry_sdk.capture_exception(ValueError("Sentry test error — ignore this"))

// JavaScript — trigger a test error
Sentry.captureException(new Error("Sentry test error — ignore this"));

Or, more dramatically, let an actual exception propagate:

# Add a temporary route to your API
@app.get("/debug-sentry")
async def trigger_error():
    division_by_zero = 1 / 0

Hit that endpoint, then check your Sentry dashboard. You should see the error within a few seconds, with a full stack trace, the exact file and line number, the request details, and the environment tag. If you see it — you're live.

Delete that route immediately after testing. Seriously.

Step 4: Set Up Meaningful Alerts

Out of the box, Sentry will email you on every new error. That gets noisy fast. Here's a better setup:

Recommended alert rules:

Critical Errors → Immediate Slack notification
- Condition: First time this error is seen
- Action: Post to #prod-alerts Slack channel
High Frequency Errors → PagerDuty
- Condition: Error occurs > 100 times in 1 hour
- Action: Trigger PagerDuty incident
New Release Regression → Email
- Condition: Error first seen in release > your-app@X.X.X
- Action: Email the engineering team

In your Sentry project: Alerts → Create Alert → Issue Alert. Spend 5 minutes here. The default "email on every event" is not what you want in production.

Step 5: Add User Context

An error without user context is frustrating to debug. Attach who was affected:

# Python — add to your auth middleware
from sentry_sdk import set_user

set_user({
    "id": str(current_user.id),
    "email": current_user.email,
    "username": current_user.username,
})

// TypeScript — after authentication
Sentry.setUser({
  id: user.id,
  email: user.email,
  username: user.username,
});

// Clear on logout
Sentry.setUser(null);

Now when errors fire, you know exactly which user was affected, can reproduce their specific flow, and can reach out to apologize before they tweet about it.

Step 6: Capture Handled Errors Too

Sentry automatically catches unhandled exceptions. But some of your most important failures are swallowed by try/catch blocks that never surface:

# Bad — error disappears silently
try:
    result = process_payment(user_id, amount)
except Exception as e:
    logger.error(f"Payment failed: {e}")  # Goes nowhere useful
    return {"error": "Payment failed"}

# Good — error goes to Sentry AND your logs
try:
    result = process_payment(user_id, amount)
except Exception as e:
    sentry_sdk.capture_exception(e)
    logger.error(f"Payment failed: {e}")
    return {"error": "Payment failed"}

// TypeScript
try {
  await processPayment(userId, amount);
} catch (error) {
  Sentry.captureException(error, {
    extra: { userId, amount },   // Add context to help debugging
  });
  throw error;
}

Payment failures, third-party API errors, queue processing failures — these are exactly the errors that stay silent in normal codebases. Capture them explicitly.

Step 7: Tag Environments and Releases

This is the feature that goes from "nice to have" to "essential" very quickly.

When you deploy a new version, Sentry should know about it:

# In your CI/CD pipeline (GitHub Actions, etc.)
export SENTRY_AUTH_TOKEN=your_auth_token
export SENTRY_ORG=your-org
export SENTRY_PROJECT=your-project

sentry-cli releases new "my-app@$(git rev-parse --short HEAD)"
sentry-cli releases set-commits --auto "my-app@$(git rev-parse --short HEAD)"
sentry-cli releases finalize "my-app@$(git rev-parse --short HEAD)"

Now in your Sentry dashboard you can:

See which release introduced an error
Filter errors by production vs staging vs development
Track your error rate across deployments
Get "Resolved in Version X" tracking

This is what lets you say with confidence: "The payment error was introduced in the 2:15pm deploy and affected 47 users."

Why This Matters More Than You Think

In 2025, Optus — an Australian telco — suffered an outage that blocked access to Triple Zero (000) emergency services for 13 hours during a routine firewall upgrade. Their monitoring systems failed to flag the problem in time, and Optus later admitted warnings weren't escalated. A configuration change, no alerting, 13 hours of invisible failure.

That's an extreme case. But the pattern is universal: teams build and ship faster than ever, and the monitoring layer is always the last thing added, never the first. In late 2025, Sentry co-founder David Cramer demoed at Enterprise Ready Conference a vision of moving from "find bugs" to "fix bugs" — because the detection problem is so solved that they can now focus on automated remediation. But you need detection working before any of that intelligence helps you.

If you vibe-coded your way to a working app, you almost certainly do not have error monitoring in place. Every real user interaction is a potential silent failure you will only hear about from a frustrated tweet.

Your 10-Minute Setup Checklist

Create Sentry account at sentry.io (free tier: 5,000 errors/month)
Create a project and choose your platform
Copy your DSN
Install the SDK (pip install sentry-sdk or npm install @sentry/node)
Initialize Sentry in your app entrypoint with DSN, environment, and release tag
Set traces_sample_rate to 1.0 in dev, 0.1–0.2 in production
Trigger a test error and confirm it appears in your dashboard
Configure Slack alerts for first-time errors (replace default email-everything)
Add set_user() / Sentry.setUser() after your authentication step
Wrap critical try/catch blocks with capture_exception()
Add release tracking to your CI/CD pipeline
Verify environment="production" so you can filter out dev noise

Do this today, before your next deploy. Not next week. Today.

Coming Up in Part 3

Next we cover structured logging with Pino and Winston — because Sentry tells you what broke, but logs tell you why. Together they give you a complete picture of what your app is doing in production.

Ask The Guild

What's the worst production error you discovered from a user complaint instead of from monitoring? Drop your story in the comments. What were you missing? What did you add afterward? The best war stories always teach the rest of us something real.

Tom Hundley is a software architect with 25 years of experience. He writes the Production Ready series for the AI Coding Guild.

Sentry in 10 Minutes: Catch Every Error Automatically