canonical: https://jentic.com/apis/pingdom.com/pingdom

# SolarWinds Pingdom API

Jentic publishes the only available OpenAPI specification for Pingdom API, keeping it validated and agent-ready. Pingdom is a website monitoring and uptime tracking service operated by SolarWinds that enables developers to programmatically create and manage uptime checks, retrieve performance data, configure alerts, and generate availability reports. The API exposes comprehensive controls for HTTP, HTTPS, DNS, ICMP, and transaction monitoring checks with multi-region test locations, customizable alert rules, and detailed historical performance metrics. Agents can use Pingdom to automate monitoring setup, integrate uptime data into dashboards, and trigger incident response workflows based on check results.

## For AI agents

Create and manage uptime monitoring checks, retrieve performance metrics, configure alerts, and track website availability across multiple global locations.

## Scope

Covers synthetic uptime monitoring and alerting only. Does not include advanced SolarWinds platform features, APM (application performance monitoring), or infrastructure monitoring. Use for website and API endpoint uptime checks.

## Capabilities

- Create and configure uptime checks for HTTP, HTTPS, TCP, DNS, ICMP, and SMTP protocols
- Monitor website performance and page load times from 100+ global test locations
- Retrieve detailed check results including response times, status codes, and outage history
- Configure alert rules and notification channels including email, SMS, webhooks, and integrations
- Set up maintenance windows to pause alerting during planned downtime
- Generate uptime reports with SLA calculations and performance summaries
- Monitor real user metrics (RUM) for actual visitor experience tracking

## Use cases

### Automated incident detection and alerting

Create uptime checks for critical services and configure multi-channel alerting to notify on-call teams when checks fail. The API enables automated check creation during deployments, integrates with incident management platforms via webhooks, and provides detailed failure context including status codes and response times to accelerate troubleshooting. Maintenance windows can be scheduled programmatically to prevent false alerts during known downtime.

Example prompt: Call POST /checks to create an HTTP check with target URL, check interval, and alert contacts. Configure POST `/alerting/contacts` and POST `/alerting/policies` to route notifications. Poll GET `/checks/{id}` for status and use GET `/checks/{id}/results` for historical data.

### Multi-region performance tracking

Monitor global website performance by creating checks from multiple test locations and aggregating response time data. The API returns per-region performance metrics that reveal geographic latency patterns, CDN effectiveness, and regional availability issues. Teams can build dashboards that compare response times across continents and identify regions requiring infrastructure improvements.

Example prompt: Call GET /checks to list all checks, then GET `/checks/{id}/results`?includeanalysis=true to retrieve detailed performance data per test location. Aggregate response times by region and render in a dashboard or alert when specific regions exceed thresholds.

### SLA compliance reporting and validation

Generate automated uptime and SLA reports for customer-facing services by querying historical check results and calculating availability percentages. The API provides outage timestamps, duration data, and uptime summaries that feed directly into customer dashboards or billing systems. Schedule periodic report generation to track SLA compliance trends and provide evidence for service level agreements.

Example prompt: Call GET `/summary.outage/{checkid}` to retrieve outage history for a time period, calculate uptime percentage from total time minus outage duration, and generate SLA compliance reports. Use GET `/checks/{id}/summary` to get pre-calculated uptime metrics.

### Agent-driven monitoring through Jentic

Let an agent fulfill a 'monitor my website and alert me if it goes down' request by routing through Jentic. The agent searches for uptime monitoring operations, loads the Pingdom check creation schema, and submits the target URL with alert preferences; Jentic injects the bearer token and returns check status without exposing credentials in the agent context.

Example prompt: Through Jentic, search('create uptime monitoring check'), load Pingdom POST /checks operation, execute with target URL, check type, and interval parameters. Poll GET `/checks/{id}` via Jentic to retrieve status and alert on failures.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/checks` | Create a new uptime or performance monitoring check |
| GET | `/checks` | List all monitoring checks in the account |
| GET | `/checks/{checkid}` | Get detailed information about a specific check |
| GET | `/checks/{checkid}/results` | Retrieve historical check results and performance data |
| PUT | `/checks/{checkid}` | Modify an existing monitoring check configuration |
| DELETE | `/checks/{checkid}` | Delete a monitoring check |
| GET | `/summary.outage/{checkid}` | Get outage history and downtime summary for a check |
| POST | `/maintenance` | Create a maintenance window to pause alerting |
| GET | `/alerting/contacts` | List all alert notification contacts |
| POST | `/alerting/contacts` | Add a new alert notification contact |

## Key resources

- **Checks** — Monitoring checks that test endpoints at regular intervals and return status, response time, and availability data.
- **Results** — Historical check result data including timestamps, response times, status codes, and per-location performance metrics.
- **Alerts** — Alert rules and notification contacts that trigger when checks fail or performance thresholds are exceeded.
- **Reports** — Uptime summaries, SLA calculations, and performance reports generated from historical check data.

## Why Jentic

- **Setup:** Wiring the Pingdom API by hand means setting up its bearer auth and coding each uptime check, results poll, maintenance window, and alerting contact call yourself. Through Jentic you install once, import Pingdom from the API Directory, store the bearer token once, and your agent calls it.
- **Permission scoping:** Pingdom puts the check id in the URL path (`/checks/{checkid}/...`), so a rule can pin your agent to reading and updating a specific check and its results. You choose the operations it may call, so deleting a check or editing alerting contacts is not included unless you add it.
- **Credential handling:** Your Pingdom bearer token is stored once, encrypted, by your own Jentic One instance and injected as the Authorization header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'monitor website uptime' or 'create an uptime check', and Jentic returns the matching Pingdom operation with its parameter schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **UptimeRobot** — Website monitoring API with simpler pricing and 50 free monitors on the basic plan.
- **StatusCake** — Uptime and performance monitoring API with additional virus scanning and domain monitoring features.

## FAQ

### Why is there no official OpenAPI spec for Pingdom API?

Pingdom does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Pingdom API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Pingdom API use?

The API uses bearer token authentication. Pass your Pingdom API token in the Authorization header as 'Bearer <token>'. Through Jentic, the token is stored encrypted in the vault and applied at execution so it never enters the agent's prompt.

### What types of monitoring checks can I create with Pingdom API?

Pingdom supports HTTP/HTTPS, TCP, DNS, ICMP (ping), SMTP, and transaction monitoring (TMS) checks. Each check type monitors different aspects of service availability and can be configured with custom intervals, test locations, and alert thresholds.

### How do I configure alerts when a check fails?

Create alert contacts via POST `/alerting/contacts` with email, SMS, or webhook destinations. Then assign contacts to checks via PUT `/checks/{checkid}` or configure advanced alert policies with custom escalation rules via the alerting endpoints.

### Can I schedule maintenance windows to prevent false alerts?

Yes. Use POST /maintenance to create maintenance windows that temporarily pause alerting for specific checks during planned downtime. Specify start time, duration, and which checks to silence.

### How do I get historical uptime data through Jentic?

Install Jentic with pip install jentic, search('get uptime history for a website'), load the Pingdom GET `/checks/{checkid}/results` operation, and execute with the check ID and time range. Jentic applies your API token automatically.

### Can I limit what my agent is allowed to do with the Pingdom API?

Yes. Because you run Jentic One yourself, your own rules decide which Pingdom operations and credentials the agent may use, so you can allow it to read and update a specific check while withholding everything else. Pingdom puts the check id in the URL path, such as GET `/checks/{checkid}` and GET `/checks/{checkid}/results`, so a rule can pin the agent to reading and updating one check and its results. Destructive or account-wide calls like DELETE `/checks/{checkid}` or POST `/alerting/contacts` stay off limits unless you explicitly add them.