Pingdom Alerts: Configuring Notifications That Actually Work

Most Pingdom alert setups fail in one of two ways: they miss real outages because alerts aren't configured correctly, or they generate so much noise that engineers start ignoring them. Both failures have the same outcome — you find out about downtime from users instead of your monitoring.

This guide covers the full Pingdom alerting stack: contacts, integrations, escalation policies, on-call schedules, maintenance windows, and status pages.

Alert Contacts

Alert contacts are the destinations where Pingdom sends notifications. Go to Alerting → Alert contacts to manage them.

Email

Add individual email addresses and team distribution lists. Email is reliable but passive — it works if someone's actively watching their inbox. Don't rely on email alone for anything requiring a response faster than 15-20 minutes.

For email alerts to be useful, route them to a shared engineering alias that feeds into your team's email-based triage process, not just individual inboxes. Personal email alerts get missed when the primary on-call engineer is unavailable.

SMS

Available on Standard and higher plans. SMS is useful for reaching engineers when other channels might be degraded. During severe infrastructure incidents, your Slack workspace might be down or slow. SMS typically gets through.

Add phone numbers for on-call engineers directly in the alert contact settings. For international teams, verify country code formatting — Pingdom needs the full international format.

Slack

Go to Integrations → Slack. Create a Slack app or use an incoming webhook in your Slack workspace, then paste the webhook URL into Pingdom.

Config decisions:

• Which channel: Create a dedicated monitoring channel (#alerts-monitoring or #pingdom). Don't route to your main engineering channel — alert noise in a high-traffic channel trains engineers to ignore it.
• When to alert: Pingdom sends Slack notifications for both "check is down" and "check is recovering." The recovery message is important — it closes the loop without requiring someone to manually check whether the issue resolved.

PagerDuty

PagerDuty is the right tool when you need guaranteed delivery with acknowledgment tracking and escalation. Go to Integrations → PagerDuty, enter your service's integration key, and Pingdom creates and resolves PagerDuty incidents automatically.

When Pingdom detects an outage, it creates a PagerDuty incident. When the check recovers, it resolves the incident. PagerDuty handles the escalation: page the on-call engineer, escalate to secondary if unacknowledged, page the manager if still unacknowledged.

This integration is worth setting up even if you have other notification channels. PagerDuty's acknowledgment workflow ensures someone actually owns the incident.

Webhooks

Pingdom supports custom webhooks for integrations not listed natively. You can integrate with:

• OpsGenie
• VictorOps (now Splunk On-Call)
• Custom incident management systems
• Internal alerting pipelines

Webhook payload is JSON with check details, status, and timestamps. Check Pingdom's documentation for the exact schema — it varies slightly between uptime and transaction check alerts.

Alert Policies

Alert contacts define where notifications go. Alert policies define when and how often to send them.

Go to Alerting → Alert policies → Add new.

Alert threshold

Alert when check has been down for X minutes: This delays the alert until the check has been failing for a specified duration. A 0-minute threshold (alert immediately) generates more false positives from transient network issues. A 2-5 minute threshold reduces noise at the cost of slightly delayed detection.

Recommendation: 0 minutes for critical production services (you want to know immediately), 2-3 minutes for less critical services.

Alert after X consecutive failures: An alternative threshold approach. "Alert after 2 consecutive failures" means the check must fail twice in a row before alerting. Since checks run every minute, this means roughly 2 minutes of confirmed failure before you're paged.

This is often more reliable than time-based thresholds because it directly filters one-time transient failures.

Escalation

Send repeated alerts: If the check is still down after N minutes, send another alert. Configure this so long outages generate reminders rather than a single notification that might be missed.

Typical config: alert immediately, repeat every 30 minutes the check is still down. Adjust based on your SLA expectations and how long outages typically last.

Escalation contacts: Alert contact A first; if not acknowledged after N minutes, also alert contact B. Pingdom's built-in escalation is simple — for complex escalation trees, use PagerDuty and let it handle the escalation logic.

Recovery notifications

Ensure recovery alerts are enabled. Knowing an outage ended is as important as knowing it started. Recovery alerts also reduce unnecessary follow-up: engineers stop monitoring a situation manually when they know the system will notify them of recovery.

Alert Fatigue Prevention

Alert fatigue is the primary reason monitoring systems fail in practice. Engineers who receive too many alerts start ignoring them, including real ones. Here's how to prevent it.

Tune check intervals and sensitivity together

A 1-minute check interval with "alert on first failure" sends an alert for every transient network blip. Consider:

• 1-minute checks with "alert after 2 consecutive failures" — catches real outages in under 2 minutes while filtering single-failure noise
• 30-second checks (on higher tier plans) with "alert after 3 consecutive failures" — even faster detection with better noise filtering

Group checks by criticality

Not all services have the same alert urgency. Create separate alert policies:

• Critical (e.g., production API, payment flow): Immediate PagerDuty incident + SMS + Slack
• High (e.g., main website, login): PagerDuty + Slack, no SMS
• Low (e.g., staging, internal tools): Slack only

Routing everything to PagerDuty at the same priority means engineers get woken up for staging environment issues. The on-call engineer stops taking alerts seriously.

Use check-level alert overrides

Individual checks can override the default alert policy. Apply this for:

• Checks that are known to be flaky during deployments (route to Slack only during deploy windows)
• Staging checks that should never page anyone at night
• Third-party dependency checks where you can't fix the issue anyway

Validate that alerts are working

Send a test alert from Alert contacts settings. Verify it arrives in every configured channel. Also verify recovery alerts work — create a check against a URL that doesn't exist, let it fail, then fix the URL and confirm the recovery notification arrives.

An alert system you've never tested is not an alert system — it's a false sense of security.

Maintenance Windows

Before any planned maintenance or deployment that could cause downtime, create a maintenance window. Go to Maintenance → Add new.

Configure:

• Name: Descriptive enough to understand later ("Weekly deploy window" or "DB migration 2024-01-15")
• Checks: Select which checks to pause. You can select all checks or just the affected ones.
• Schedule: One-time or recurring. Recurring maintenance windows are useful for teams with regular deployment windows (e.g., every Tuesday 2-4am).
• Time zone: Critical to get right. Pingdom stores times in UTC — if you're scheduling a window for "Tuesday night," confirm which UTC offset applies.

Maintenance windows have two effects:

1. Suppress alerts during the window — you won't get paged for downtime you caused intentionally
2. Exclude downtime from SLA calculations — the maintenance period doesn't count against your uptime percentage

If you forget to create a maintenance window before a deployment, you can't retroactively exclude the downtime from reports. Create maintenance windows before, not after.

For CI/CD pipelines that deploy frequently, consider using the Pingdom API to programmatically create maintenance windows as part of your deployment process. The API endpoint is POST /api/3.1/maintenance — create the window at deploy start, delete it when deploy completes.

Status Pages

Pingdom offers public status pages that display real-time and historical status of your checks. Go to Status pages → Add new.

Status pages are customer-facing. When your service is degraded or down, users can check the status page rather than flooding your support channel with "is X down?" queries.

Configuration:

• Custom domain: Map a subdomain (e.g., status.yourapp.com) to the Pingdom status page via CNAME. This keeps your branding consistent.
• Checks to display: Select which checks appear on the status page. You typically don't want to expose every internal check — show the services users care about (API, web app, background jobs).
• Historical uptime: Pingdom can display the last 30 days of uptime history. This is useful for demonstrating your reliability track record.
• Subscriber notifications: Users can subscribe to the status page and receive email notifications when status changes. This reduces support load during incidents.

Status pages update in real-time as Pingdom checks pass and fail. There's no manual intervention needed — if your check detects an outage, the status page automatically marks that service as "down."

What to display

A common mistake is displaying too much on the status page. From a user's perspective:

• They don't care about your internal API vs. your public API distinction
• They don't care about which probe location is failing
• They care whether the features they use are working

Group checks into meaningful service components: "Web Application," "API," "Authentication," "Background Jobs." Map your internal checks to these high-level components.

Integrating with Incident Management

For teams with formal incident management processes, Pingdom should be a trigger, not the full system. Pingdom detects and notifies; your incident management process handles response, communication, and post-mortem.

Typical integration:

1. Pingdom detects outage → creates PagerDuty incident
2. On-call engineer acknowledges in PagerDuty → starts incident response
3. Incident commander updates status page manually with incident description and updates
4. Pingdom detects recovery → resolves PagerDuty incident
5. Team runs post-mortem, updates runbooks

Pingdom's status page auto-updates on check recovery, but doesn't support writing incident updates. If you need to communicate "we're investigating the API slowness" to users, you'll update the status page manually or use a dedicated incident communication tool like Atlassian Statuspage.

The point of all this configuration: your alerting system should tell the right person, in the right channel, with the right urgency, at the right time. That requires deliberate setup. The defaults are fine for getting started, but invest the hour to configure proper contact groups, escalation policies, and maintenance windows. Your future self at 3am will appreciate it.