Pingdom MCP Server

Pingdom

Website and API monitoring service (SolarWinds). Provides uptime checks, response time tracking, outage detection, and alert notifications. Monitors from 100+ global probe locations.

Entity Hierarchy

• Checks — the core entity. Each check monitors one URL/hostname at a configured interval (1-60 min). Types: HTTP, TCP, UDP, DNS, SMTP, IMAP, POP3, PING. Each check has a unique integer id, a name, hostname, status (up/down/unconfirmed_down/unknown/paused), resolution (check interval in minutes), and lastresponsetime (ms).
• Performance summaries — aggregated response time data for a check over a period, split into sub-intervals (hourly/daily/weekly). Each interval reports avgresponse (ms) and optionally uptime/downtime seconds.
• Uptime summaries — overall average response time and total up/down/unknown seconds for a check over a period. The basis for SLA calculations (uptime % = totalup / (totalup + totaldown) * 100).
• Outages — state transition history for a check. Each entry has status (up/down/unknown), timefrom, and timeto as UNIX timestamps. Shows exactly when downtime started and ended.
• Alerts — notification history. Each alert records who was notified (username, sentto), when (time), via what channel (email/sms/twitter/iphone/android), delivery status, and a human-readable messagefull with downtime duration.

Workflows

1. Current status overview: Enumerate checks → review status and lastresponsetime for each.
2. Performance investigation: Enumerate checks → pick one by ID → fetch performance with resolution=hour to see response time trends → pull uptime summary with includeuptime=true for SLA numbers.
3. Outage report: Enumerate checks → fetch outages for a check (order=desc for most recent) → correlate with alerts to see who was notified.
4. SLA calculation: Pull uptime summary with includeuptime=true → calculate: totalup / (totalup + totaldown) * 100 = uptime %.
5. Alert audit: Fetch alerts filtered by check or time range → review delivery status and channels.
6. Set up monitoring: Create a check (name + host + type) → configure resolution and alert thresholds → enumerate checks to confirm.
7. Manage checks: Update an existing check to change resolution, pause/unpause, or modify alert settings. Delete a check when monitoring is no longer needed (irreversible — loses all historical data).

Timestamps

All time parameters (from_ts, to_ts) and response fields (timefrom, timeto, time, lasttesttime) are UNIX timestamps (seconds since epoch). Convert to human-readable dates for display.

Gotchas

• Check IDs are integers, not strings. Always pass as integer type.
• Response times in milliseconds: lastresponsetime and avgresponse are in ms.
• Default time ranges: Performance and outage views default to ~1 week of data if no from/to specified. Summary.average defaults to the full account history.
• Rate limits: Separate burst vs sustained quotas—slow down when responses indicate you hit the cap.
• Probe locations: Performance data can be filtered/split by probe. Use bycountry or byprobe parameters on uptime summary for geographic breakdown.