Monitoring Frontend Errors with Sentry + Alerting on PagerDuty

Your guide to setting up a robust alerting pipeline for your frontend applications

Have you ever been woken up at 3 AM by a frantic customer support message about a broken checkout flow? Or worse, discovered an issue from a user complaint rather than your monitoring tools? If you're shipping frontend applications, you know the pain of catching errors before your users do.

In this article, I'll walk you through setting up a complete error monitoring and alerting pipeline using Sentry and PagerDuty. By the end, you'll have a system that automatically notifies your on-call engineers when critical frontend issues occur — complete with all the context needed to fix them fast.

Why Sentry + PagerDuty?
Before diving into the setup, let's talk about why this combination is so powerful.

Sentry gives you full-stack error monitoring with rich context — stack traces, user environment, breadcrumbs, and even session replays. It helps developers fix problems in real-time by surfacing code-level details about exceptions and crashes .

PagerDuty handles the incident response side — escalation policies, on-call rotations, and reliable notifications. When combined, Sentry alerts trigger PagerDuty incidents, connecting the "what broke" with "who needs to fix it" .

The result? Your team gets paged with all the information needed to fix issues immediately, reducing mean time to resolution (MTTR) significantly .

Setting Up the Integration
Step 1: Install the PagerDuty Integration in Sentry
First, you'll need to connect Sentry to PagerDuty. You'll need Sentry owner, manager, or admin permissions for this .

Navigate to Settings > Integrations in your Sentry organization

Find PagerDuty and click Add Installation

You'll be redirected to sign into PagerDuty and choose the account to connect

Add the PagerDuty services you want Sentry to send incidents to

Click Connect once you've added your services

Note for self-hosted Sentry: You'll need to set up a PagerDuty app first. Go to https://{YOUR_PAGERDUTY_SUBDOMAIN}.pagerduty.com/developer/applications, create a new app with "Events Integration" functionality, and add your Sentry domain to the redirect URLs .

Step 2: Configure Alert Rules
Once the integration is installed, you need to create alert rules that will trigger PagerDuty notifications.

For Issue Alerts
When setting up an alert rule:

Go to Alerts and click Create Alert

In the actions dropdown, select Send a PagerDuty notification

Choose your account and service

Select a custom severity or use the default mapping:

critical for fatal errors

error for errors

warning for warnings

info for debug and info issues

For Metric Alerts
Metric Alerts are especially powerful for monitoring the overall health of your product. They let you :

Filter on any event tags or attributes

Set separate warning and critical thresholds

Alert when event volume goes below a threshold

Jump directly from an alert into a curated Discover view

The setup is similar: create a Metric Alert, and in the actions, select your PagerDuty service .

Step 3: Frontend Error Monitoring Setup
Now that your alerting pipeline is ready, let's make sure Sentry captures meaningful frontend errors.

Basic Setup (React Example)
javascript
import * as Sentry from '@sentry/react';
import { BrowserTracing } from '@sentry/tracing';

Sentry.init({
dsn: process.env.SENTRY_DSN,
environment: process.env.NODE_ENV,
release: process.env.APP_VERSION, // Critical for source maps
integrations: [new BrowserTracing()],
tracesSampleRate: 0.1, // Adjust based on your needs

// Filter out noise
allowUrls: [/yourdomain.com/],
denyUrls: [/extensions\//, /^chrome:\/\//],

beforeSend(event, hint) {
// Remove sensitive data
if (event.request?.headers) {
delete (event.request.headers as any).Authorization;
}

// Filter known noise
const msg = hint?.originalException?.message || event.message || '';
if (/ResizeObserver loop limit exceeded/i.test(msg)) {
  return null; // Discard common noise
}

return event;

},
});
Add Error Boundaries
React error boundaries catch component-level errors and send them to Sentry:

javascript
import { ErrorBoundary } from '@sentry/react';

function Fallback({ error }: { error: Error }) {
return

Something went wrong: {error.message};
}

function App() {
return (



);
}
Capture Unhandled Rejections
javascript
window.addEventListener('unhandledrejection', (e) => {
Sentry.captureException(
e.reason instanceof Error ? e.reason : new Error(String(e.reason)),
{ tags: { type: 'unhandledrejection' } }
);
});
Step 4: Adding Context for Better Alerts
The real power comes from adding context that helps your on-call engineer understand the impact immediately.

Add Business Tags
javascript
try {
// Checkout flow
} catch (error) {
Sentry.captureException(error, {
tags: {
feature: 'checkout',
severity: 'critical',
environment: 'production'
},
extra: {
cartSize: 3,
paymentMethod: 'credit_card',
userId: getUserId()
},
user: {
id: getUserId(),
email: getUserEmail(),
// Be careful with PII!
}
});
}
Custom Fingerprinting
Sentry groups similar errors automatically, but sometimes you want more control:

javascript
Sentry.captureException(error, {
fingerprint: ['api-error', 'payment-gateway', '500'],
tags: { route: '/checkout', feature: 'payment' }
});
This helps you create alerts based on specific error groups .

Real-World Alerting Strategies
Based on real-world use cases from companies like Flexport and incident.io , here are effective alerting strategies:

1. New Issue Alerts
   Trigger when a new issue appears in production. This catches regressions and new bugs immediately.

2. High-Frequency Alerts
   Example: More than 50 errors in 5 minutes, or error rate exceeding 0.5% of sessions.

3. Release Health Monitoring
   Compare error rates between releases. If a new release shows a 30% increase in errors, alert immediately .

4. Business-Critical Flow Monitoring
   Alert on specific features like checkout, login, or payment processing — even if overall error rates are low .

Reducing Alert Fatigue
Too many alerts create noise and make your team ignore pages. Here's how to stay sane:

Filter Out Noise
Use Sentry's beforeSend and denyUrls to filter browser extensions, known harmless errors, and third-party script errors .

Use Debouncing
incident.io uses a debounce window per service — if the same service fails twice within 30 minutes, you only get one incident . You can achieve similar results with Sentry's alert rules.

Set Proper Thresholds
Start with generous thresholds and tighten them over time. It's better to have a few false negatives than constant alert fatigue.

Beyond Basic Alerting
Creating an Incident Response Workflow
Here's how incident.io structured their response flow :

Error occurs → Sentry captures it

Sentry triggers PagerDuty alert

PagerDuty pages the on-call engineer

incident.io creates an incident in triage state

The Sentry error and PagerDuty alert are attached to the incident

Engineer fixes the issue and resolves it

This creates one place to go for everything related to an incident — no hunting through different tools.

Using Sentry's Release Health
Set up release tracking so you know exactly which version introduced an issue:

javascript
Sentry.init({
release: process.env.APP_VERSION, // From your build process
environment: process.env.NODE_ENV,
});
Then create alerts that only trigger when errors affect specific releases .

Verification and Testing
Before going live:

Test in staging: Trigger a test error and verify it reaches PagerDuty

Check context: Ensure the error has the right tags, breadcrumbs, and user context

Review alert rules: Test your thresholds and make sure they're not too sensitive

Practice the response: Run through the alert → fix → resolve workflow

Final Thoughts
Setting up Sentry with PagerDuty transforms your frontend error monitoring from reactive fire-fighting to proactive incident management. The combination provides:

Rich error context from Sentry

Reliable alerting from PagerDuty

Clear escalation paths for your on-call teams

Start simple — monitor critical flows and set up basic alerts. Then iterate based on what you learn. The goal isn't to catch every error; it's to catch the ones that matter to your users and business.

Remember: the best alert is the one that leads to a fix before a user notices anything wrong. With Sentry and PagerDuty working together, you'll be well on your way.

Have you implemented this setup? Share your experiences and tips in the comments below!

Comments

[Md. Anwar Hossain]

Great breakdown of the full flow. One thing I’ve found in setups like this is that the hardest part isn’t alerting itself, but preserving enough context so you don’t have to reconstruct state across tools during triage.

Some newer error tracking tools like Muscula are trying to reduce that gap by bundling more request-level context directly into the error view, rather than relying purely on external logs and dashboards. The direction feels more interesting than the alerting layer itself right now.