PagerDuty Vendor Outage Alerts: How to Page the Right Incidents and Suppress Noise

PagerDuty is excellent at getting human attention, which is exactly why vendor outage alerts must be filtered carefully. If every external status page update creates an incident, on-call engineers will stop trusting the signal. If no external outage creates an incident, customers may detect critical vendor failures before your team does.

The right setup pages only when a vendor incident threatens a customer-facing workflow, revenue path, or enterprise commitment. Everything else should route to lower-urgency channels such as Slack, Microsoft Teams, or an operations dashboard.

This is where dependency tiering matters. A major outage from your payment processor and a minor maintenance update from a low-risk analytics tool should not share the same escalation path. The event source may be similar, but the business impact is not.

Tier 1 dependencies page immediately when they hit partial outage or major outage. These are services where failure directly blocks core customer workflows: payments, authentication, primary database, DNS, CDN, and production cloud regions.

Tier 2 dependencies notify the owning team without paging. They may degrade product quality or internal operations but do not usually require a wake-up call. Examples include secondary analytics, non-critical notification providers, documentation hosting, or deployment tools outside emergency windows.

Tier 3 dependencies stay visible but quiet. These are useful to monitor for situational awareness, but they should not interrupt anyone unless combined with other signals. A weekly reliability review is often the right place for Tier 3 patterns.

Create dedicated PagerDuty services for critical vendor dependencies or route them into an existing production incident service with clear event metadata. Include vendor name, component, severity, region, affected workflow, and a link to the monitoring detail page.

Suppress planned maintenance unless the maintenance affects a workflow that your customers rely on during the window. Maintenance notices are useful, but they are not automatically incidents. The alert rule should distinguish scheduled work from unexpected degradation.

Test the path quarterly. Send a test vendor outage alert, confirm the PagerDuty incident opens with useful context, verify escalation policy, and confirm the linked runbook is still accurate. A broken routing key is invisible until the worst possible moment.

Should vendor outages page on-call? Only vendor outages that threaten critical customer workflows should page on-call. Lower-impact vendor issues should route to team channels or dashboards to preserve alert trust.

What metadata should be included? Include vendor, affected component, severity, region, impacted customer workflow, first detected time, current vendor status, and the runbook link.

How do you reduce false positives? Use dependency tiering, severity thresholds, maintenance suppression, and component filters. Review noisy alerts after every on-call rotation and adjust rules quickly.