Getting Started with Pingdom: Set Up Your First Uptime Monitor
Setting up Pingdom takes about 15 minutes. Getting it configured to actually be useful takes a bit more thought. This guide walks through the full setup — account creation, your first HTTP check, alert contacts, and reading the reports — with the decisions explained, not just the clicks.
Account Setup
Pingdom is now part of SolarWinds. You sign up at pingdom.com and get redirected to the SolarWinds portal. Choose the plan based on your check count and features needed:
- Starter: Basic uptime checks, limited locations, email alerts only
- Standard: More checks, SMS alerts, integrations (Slack, PagerDuty)
- Advanced: Transaction monitoring, more check slots, public status pages
For most teams starting out, Standard is the right tier — you need integrations and SMS for on-call to work properly.
After account creation, you land in the Pingdom dashboard (not SolarWinds Observability, the dedicated Pingdom UI at my.pingdom.com). The two UIs coexist and it's confusing — use my.pingdom.com for everything covered here.
Creating Your First HTTP Uptime Check
Go to Uptime → Add new → Uptime check.
Basic settings
Name: Make it descriptive. "Production API" is better than "Check 1". You'll have dozens of checks eventually — name them so you know what failed at 3am without clicking into it.
Check type: Select HTTP(S) for a standard web request check.
URL: Enter the full URL including protocol. Use https:// — if your site serves HTTP, either fix that or check both. If you have a health endpoint (/api/health, /healthz, /_health), use that instead of the homepage. Health endpoints are purpose-built for this: they return fast, don't trigger side effects, and usually check downstream dependencies.
Check interval
Options range from 1 minute to 60 minutes. The interval determines your worst-case detection latency — a 5-minute interval means an outage could run for up to 5 minutes before Pingdom detects it.
For production services: 1-minute intervals. The cost difference between 1-minute and 5-minute checks on a paid Pingdom plan is negligible, but the difference in detection speed is significant.
For staging or non-critical monitoring: 5 minutes is fine.
Probe locations
This is where most people underinvest. Pingdom has 100+ probe locations. Select at least 3-5 from different regions. If your users are primarily in Europe, pick locations in Western Europe, Central Europe, and at least one in North America as a control.
Why multiple locations? A single probe can have network issues unrelated to your service. Two or three locations failing simultaneously is much more likely to be a real outage. Pingdom lets you configure the alert threshold — you can set it to alert when 2 of 3 locations, or 3 of 5 locations, detect failure.
For a global product, cover: US East, US West, UK or Germany, Singapore or Australia. That's your baseline.
Connection settings
Timeout: How long to wait before marking the check as failed. Default is usually 30 seconds — far too generous. Check your actual response time baseline (Pingdom shows this in the uptime report once you've had checks running). Set timeout to 3-5x your normal response time. If your API normally responds in 200ms, a 5-second timeout is reasonable. A 30-second timeout means you could have a severely degraded service that Pingdom considers "up."
Authentication: If you're checking a protected endpoint, enter credentials here. Don't check a page that requires authentication from anonymous probes — you'll always get a 401 or redirect.
Response verification
This is the most important configuration most people skip.
Under Additional settings, enable Check for string in response. Enter a string that only appears in a successful response.
Examples:
- For a health endpoint:
{"status":"ok"}or"healthy" - For a webpage: A unique phrase from your actual content, not from your 500 error page or maintenance page
Without string verification, Pingdom considers a 200 response "up" regardless of body content. A misconfigured load balancer returning a 200 with "Service Unavailable" in the body will fool a status-code-only check. String verification catches this.
If you're checking an API, you can also enable Check for JSON and specify expected values, though simple string matching covers most cases.
Configuring Alert Contacts
Go to Alerting → Alert contacts → Add new.
Email alerts
Add your personal email and your team distribution list. Email alerts are the fallback — they're reliable but slow if you're not actively watching your inbox.
Slack integration
Go to Integrations → Slack. You'll need a webhook URL from your Slack workspace (Settings → Apps → Incoming Webhooks). Paste the webhook URL into Pingdom and select which Slack channel receives alerts.
Recommendation: Create a dedicated #alerts-monitoring channel (or #pingdom-alerts) rather than routing to your main engineering channel. Alert fatigue from noise in a high-traffic channel will cause people to start ignoring notifications.
PagerDuty integration
If your team uses PagerDuty for on-call rotation, connect Pingdom to it. Go to Integrations → PagerDuty, enter your integration key, and Pingdom will create incidents in PagerDuty when checks fail and auto-resolve when they recover.
This is the setup that actually pages the on-call engineer. Email and Slack are good for visibility; PagerDuty is for waking someone up.
SMS alerts
Available on Standard and higher plans. Add phone numbers directly in Alert contacts. SMS is reliable in situations where internet connectivity is degraded — during infrastructure incidents, your Slack or email might be affected. SMS often gets through when other channels don't.
Creating an Alert Policy
Alert contacts are the destinations. Alert policies are the rules for when to use them.
Go to Alerting → Alert policies → Add new.
Configure:
- When to alert: On first failure vs. after N consecutive failures. "First failure" is more sensitive but generates more noise from transient issues. "After 2 consecutive failures" reduces false positives without much real-world impact — a second consecutive failure is almost always a real problem.
- Contacts to notify: Add your contact groups
- Repeat alerts: If the check is still failing after N minutes, alert again. Useful for long outages where you want periodic reminders.
Assign the alert policy to your checks under each check's settings.
Running Your First Check
After saving the check, Pingdom immediately starts monitoring. You'll see the check appear in your uptime list with status "Checking" for the first few minutes.
The first useful data appears after 5-10 check cycles. At that point, you can see:
- Current status (up/down)
- Response time from each probe location
- Uptime percentage for the current day/week/month
Reading the Uptime Report
Click into a check and select the Reports tab (or go to Reports → Uptime).
The report shows:
- Uptime percentage for the selected period
- Outage log: Each downtime event with start time, duration, and response time at detection
- Response time graph: Shows latency trends over time. Sustained increases in response time often precede outages.
- Location breakdown: Response times by probe location. If one region is consistently slower, you may have a CDN or routing issue.
What to look for
Consistent response time increases: If your API response time climbs from 200ms to 800ms over a week without an outage, something is degrading. Pingdom's response time history helps you catch this before it becomes an outage.
Regional discrepancies: If Singapore probes are 3x slower than US probes and most of your users are in Asia, you have a CDN or GeoDNS problem that uptime checks won't catch but response time data will reveal.
Frequent short outages: Multiple 1-2 minute outages that don't trigger your alert threshold (if you've set it to 2+ consecutive failures) may indicate intermittent instability. Look at the outage log for patterns — same time of day, same probe location, etc.
Setting Up a Maintenance Window
Before any planned maintenance, go to Maintenance → Add new.
Configure:
- Start and end time
- Which checks to pause
- Optional: recurring schedule (weekly maintenance windows)
Maintenance windows prevent false alerts during deployments and keep planned downtime out of your SLA calculations. Always set these up before taking the app down — you can't retroactively exclude downtime from reports.
Next Steps
Once your first check is running and you've confirmed alerts work (use the Test alert button in alert contact settings), expand your coverage:
- Add checks for your key user flows, not just the homepage
- Add a transaction check for your most critical user path (signup, login, checkout)
- Set up a public status page if you have external users or SLA commitments
- Review alert policies to tune for your team's on-call structure
The goal is coverage across the paths that matter to users, with alerts that go to the right people at the right urgency level. A Pingdom account with 50 checks all alerting to one email alias is less useful than 10 well-configured checks with proper routing.
