Uptime Monitoring & Status Pages
Pingdom
Rest of world Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by SolarWinds Worldwide, LLC · www.pingdom.com
Compare with StatusCake → Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
Pingdom at a glance
- Vendor
- SolarWinds Worldwide, LLC
- Headquarters
- Not stated on the vendor’s pages as of 1 Nov 2026
- Data hosting
- Not stated on the vendor’s pages as of 1 Nov 2026
- Free plan
- Not stated on the vendor’s pages as of 1 Nov 2026
- Panel verdict
- The AI panel rates Pingdom 1.5/5, the mean of 6 judges. Pingdom, from SolarWinds Worldwide, LLC (USA, with SolarWinds Software Europe DAC in Ireland per the SolarWinds privacy policy), is judged here on a single captured page: its public API documentation. how scores are made
- As of
- Vendor pages captured 1 Nov 2026; evaluated by the panel 2 Nov 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Pingdom, from SolarWinds Worldwide, LLC (USA, with SolarWinds Software Europe DAC in Ireland per the SolarWinds privacy policy), is judged here on a single captured page: its public API documentation. It is strongest where that documentation is richest — checks and locations scores 5–6 for HTTP, TCP, ping, DNS, UDP and mail checks, keyword validation, certificate verification with days-before-expiry alerting, one-minute check resolution, probe regions EU, NA, APAC and LATAM, and transaction checks by script or recording. Everything around the customer is bare: status pages scores 0, alerting and on-call and reports and reliability each score 2, with no public information on alert channels, escalation, on-call schedules, uptime or SLA reports, or retention. Automation and teams scores 4–5 on a REST API at version 3.1 with a downloadable OpenAPI specification and bulk check changes, though the capture shows nothing on single sign-on, team roles or audit logs. The widest spread is sovereignty, 0–2: the security officer weighed the named contracting entities while five of six judges scored 0 on a capture silent on residency, subprocessors and a data processing agreement.
Speaks for it
- Checks and locations scores 5–6, with HTTP, TCP, ping, DNS, UDP and mail checks, keyword content validation, and certificate verification that treats an invalid certificate as down
- Transaction checks can be built from a script or a browser recording, with click, fill and wait steps and page-state validations that judges tied to testing checkout and login flows
- Check resolution runs down to one minute, with probes selectable across the EU, NA, APAC and LATAM regions
- Automation and teams scores 4–5 on a documented REST API at version 3.1 with a downloadable OpenAPI specification, read or read/write tokens, and a bulk call to pause or re-time many checks at once
Held against it
- Status pages scores 0, with no public information on incident pages, components, subscribers or custom domains
- Alerting and on-call sits at 2, with no public information on delivery channels, escalation rules, on-call schedules or what messages cost
- Reports and reliability sits at 2, with no public information on uptime or SLA reports, retention periods, export, or the vendor's own availability record
- We found no public information on confirming a failure from a second probe before alerting, private probe locations, heartbeat or cron checks, or maintenance windows
- Every sovereignty attribute is unknown; the captured material names only the contracting entities — SolarWinds Worldwide, LLC in the USA, with SolarWinds Software Europe DAC in Ireland, per the SolarWinds privacy policy
Best for
- You want broad synthetic coverage — HTTP, TCP, ping, DNS, UDP and mail checks with certificate monitoring — at one-minute resolution across the EU, NA, APAC and LATAM regions
- You need to monitor a multi-step user flow such as checkout or login, using transaction checks built from a script or a browser recording
- Your team wants to manage checks programmatically, with a REST API at version 3.1, a downloadable OpenAPI specification and a bulk call to pause or re-time many checks at once
Avoid if
- You need a customer-facing status page with components, incident updates and subscribers — the status pages criterion is scored 0
- Your on-call rotation depends on documented alert channels, escalation and acknowledgement; alerting and on-call sits at 2, showing alerts fire but not how they reach a person overnight
- You must show uptime or SLA history for a renewal or a client report; reports and reliability sits at 2, with no public information on uptime reports, retention or export
- You cannot contract before data residency and a data processing agreement are proven; every sovereignty attribute is listed as unknown, and scores run 0–2
The scores
| Criterion | Panel median |
|---|---|
| Checks, locations & failure confirmation | 3 of 5 |
| Alerting, escalation & on-call | 1 of 5 |
| API, monitoring as code & team administration | 2 of 5 |
| Uptime reports, data & the vendor's own reliability | 1 of 5 |
| European sovereignty | 1 of 5 |
Checks, locations & failure confirmation
Show reasoningHide reasoning
How this is scored
What can be monitored and how reliably a failure is detected: HTTP(S) with status code and keyword checks, TCP and port, ping, DNS records, SSL certificate and domain expiry, cron jobs and heartbeats, multi-step API checks with assertions, browser or transaction checks of a login or checkout, the shortest check interval, the number and regions of probe locations, the re-check from a second location before an alert, timeouts and response time thresholds, and private locations inside the customer's own network.
0 — Runs no checks of its own; a status page or alerting tool that only receives signals from other monitors.
3 — HTTP checks of a URL at a fixed interval with an up or down result; keyword, SSL, cron and the probe locations are basic or not described.
5 — HTTP(S), keyword, TCP or port, ping and SSL expiry checks, cron or heartbeat monitoring, an interval of one minute or less, several named probe locations, a failure confirmed from a second location before alerting, and response times recorded per check.
8 — Multi-step API checks with assertions on headers and body, browser or transaction checks of a user flow, DNS and domain expiry checks, sub-minute intervals, probe locations listed by city with the confirmation logic documented, private locations or agents for internal services, and maintenance windows that pause checks.
10 — Coverage and accuracy a reliability team runs on: every check type above with code-based checks (for example Playwright or scripted tests) in version control, location-specific thresholds, false-positive handling and probe health published, and the detection method documented so a result can be reproduced.
The Agency Developer
The API documents HTTP checks with keyword matching, TCP, ping, DNS, UDP and mail protocol checks, SSL verification that treats an invalid certificate as down with warnings ahead of expiry, check intervals down to one minute, probe regions across EU, North America, APAC and Latin America, and browser transaction checks created by script or recording. That covers most of what I need across client sites, but I found no public information on domain expiry checks, cron or heartbeat monitoring, a confirming re-check from a second probe before alerting, private probes or maintenance windows. 1
The SaaS Platform Engineer
The captured documentation lists HTTP, custom HTTP, TCP, ping, DNS, UDP and mail checks with keyword content rules, certificate verification with days-before expiry, a one-minute minimum test resolution, and transaction checks built from a browser recording with page-state validations — close to what I need for testing a login flow. Probes are selectable only as regions (EU, NA, APAC, LATAM), not named cities. I found no public information on confirming a failure from a second location before alerting, heartbeat checks, private probes inside our network, or maintenance windows, and that confirmation step is what keeps my rotation from being woken by one flaky probe. 1
The Customer Support Lead
The captured documentation lists HTTP, TCP, ping, DNS, UDP and mail protocol checks, keyword validation, certificate checks, a fastest test frequency of one minute, probe regions in Europe, North America, APAC and Latin America, and recorded browser transactions with click, fill and wait steps — enough coverage that a payroll outage would be caught. What I could not find described is heartbeat monitoring for background jobs, confirmation from a second probe before alerting, private probes inside our own network, or maintenance windows, so it lands just past the middle rather than higher. 1
The E-Commerce Operations Manager
The API documentation shows HTTP(S) checks with contains and not-contains matching, TCP, ping, DNS, UDP and mail protocol checks, certificate verification with alerting days before expiry, a one-minute minimum interval, probe regions across EU, North America, APAC and Latin America, and transaction checks as script or browser recording with go-to, click and fill steps and page-state validations — that is exactly how I would test the checkout and payment page rather than just the homepage. We found no public information on confirming a failure from a second location before alerting, maintenance windows, cron or heartbeat checks, or private probe locations inside our network. 1
The Information Security Officer
The API documents HTTP, keyword, TCP, ping, DNS, UDP and mail-protocol checks with certificate validation and days-before-expiry down alerts, a one-minute check interval, four probe regions, and scripted or recorded transaction checks with page-state validations. We found no public information on heartbeat or cron monitoring, confirmation from a second location before alerting, private probes inside our own network, or maintenance windows. 1
The Skeptic
The API documentation shows real breadth: HTTP, TCP, ping, DNS, UDP and mail checks, keyword validation, certificate checks with a days-before-expiry trigger, transaction checks that are scripted or recorded, and a one-minute resolution. But probes are selectable only by broad region — EU, NA, APAC, LATAM — with no city list or count, and we found no public information on confirming a failure from a second location before alerting, private locations, or maintenance windows, which is the part I care most about. 1
Alerting, escalation & on-call
Show reasoningHide reasoning
How this is scored
How the right person learns about a failure: alert channels (email, SMS, phone call, push app, Slack, Microsoft Teams, Telegram, webhooks), alerts to PagerDuty, Opsgenie or similar tools, escalation policies when an alert is not acknowledged, on-call schedules and rotations, acknowledge and resolve from the app, alert grouping and noise reduction, recovery notifications, maintenance windows that mute alerts, and whether SMS and calls are included or charged per message.
0 — No alerting at all; results can only be viewed in the dashboard.
3 — Email alerts and one or two chat integrations; escalation, phone calls and schedules are basic or not described.
5 — Email, SMS, a mobile push app, Slack, Microsoft Teams and webhooks, alerts forwarded to PagerDuty or Opsgenie, per-monitor alert contacts, recovery notifications, a delay or threshold before alerting, and maintenance windows that mute alerts.
8 — Phone call alerts, escalation policies with timeouts, on-call schedules and rotations with overrides, acknowledge and resolve from the app or chat, alert grouping, incident timelines with who did what, and the price of SMS and calls stated per country or included in the plan.
10 — On-call that replaces a separate incident tool: follow-the-sun schedules, escalation across teams, alert routing by service and severity, post-incident reviews generated from the timeline, and delivery of every alert channel monitored and reported.
The Agency Developer
Down alerts clearly exist — an invalid certificate or a response time above a set number of milliseconds is treated as down, and past alerts can be listed through the API. Beyond that I found no public information on channels such as email, SMS, push, Slack or webhooks, on escalation, on-call schedules, or the cost of SMS and phone calls. 1
The SaaS Platform Engineer
The documentation shows checks trigger down alerts, including when response time crosses a configured limit, and an API endpoint returns the alert actions generated for the account. Beyond that I found no public information on delivery channels, phone-call or SMS costs, escalation policies, on-call schedules, or maintenance windows that mute alerts. It tells me alerts fire, but not how they reach a human at 3 a.m. 1
The Customer Support Lead
The only alerting facts on record are that alerts are generated and can be listed through the API, and that a slow response can itself raise a down alert. I found no public information on alert channels such as email, SMS or chat, escalation rules, on-call schedules, or what messages cost, so I cannot give it weight. 1
The E-Commerce Operations Manager
All the captured page proves is that a down alert is triggered when a check fails or exceeds a response-time limit, and that past alerts can be listed through the API. We found no public information on alert channels — SMS, phone call, push, Slack, Teams — escalation policies, on-call schedules or what messages cost, so I cannot tell from this whether whoever is on duty at 3 a.m. in May would even be woken. 1
The Information Security Officer
The documentation shows alerts generated when a response time exceeds a set value in ms or a certificate fails verification, plus an endpoint listing past alerts, but we found no public information on delivery channels, escalation policies, on-call schedules, acknowledgement, or the cost of SMS and phone alerts. For my on-call staff I need far more than proof that an alert fires. 1
The Skeptic
The capture proves alerts are generated — a down alert on a response-time threshold (restricted from Starter and Free plans), an invalid certificate treated as down, and an endpoint returning the alerts an account has produced. Not one alert channel, escalation rule, on-call schedule or per-message price appears on the captured pages, so I cannot vouch for how a page reaches a human at 3 a.m. 1
Status pages & incident communication
n/r
n/r
n/r
n/r
n/r
n/r
Show reasoningHide reasoning
How this is scored
How customers and colleagues are told: public status pages on a custom domain with SSL, components and component groups fed automatically by monitors or set by hand, incident updates and scheduled maintenance announcements, subscribers notified by email, SMS, RSS or webhook, uptime history shown per component, private or password-protected pages for internal teams or single customers, branding and custom CSS, several languages, page templates, and how the status page itself stays online when the main product is down.
0 — No status page of any kind.
3 — A public status page listing monitors with their current state; custom domain, incident updates and subscribers are basic or not described.
5 — Public status pages on a custom domain, components linked to monitors, incident updates and scheduled maintenance, email subscribers, uptime history per component, the vendor's branding removable, and a password-protected or private page option.
8 — Component groups, SMS, RSS and webhook subscribers with per-component subscriptions, private pages with single sign-on or IP restriction, several languages, incident templates, embeddable status widgets, audience-specific pages for single customers, and the status page hosting kept separate from the main service and documented.
10 — Incident communication end to end: incidents drafted from monitor events and approved by a person, updates published to the page, subscribers, chat and social channels at once, a full incident archive with post-mortems, status page uptime published, and accessibility of the page stated.
The Agency Developer not rated — no public information
I found no public information on status pages; the captured API documentation covers only checks, alerts, transaction scripts and probes, with nothing on custom domains, components, incident updates or subscriber notifications. 1
The SaaS Platform Engineer not rated — no public information
We found no public information on status pages, incident updates, or subscriber notifications; the captured documentation covers the monitoring API only, and no facts about pages or incidents appear there. 1
The Customer Support Lead not rated — no public information
This is the capability I care about most — a page on our own domain with components, templates, subscribers and uptime history — and I found no public information on any of it: the one captured page is API documentation and describes no status page, incident updates or subscribers. The vendor is categorised under uptime monitoring and status pages, but no captured page substantiates a single page feature. 1
The E-Commerce Operations Manager not rated — no public information
We found no public information on status pages of any kind: the captured API documentation covers checks, alerts and root-cause analysis, and says nothing about a customer-facing page, components, incident updates, subscribers or hosting of the page itself. 1
The Information Security Officer not rated — no public information
We found no public information on status pages, custom domains, components, incident updates or subscriber notifications; the captured API documentation is silent on the subject. 1
The Skeptic not rated — no public information
We found no public information on status pages, incident communication, subscribers or custom domains; the single captured page is API documentation that never mentions any of it. 1
API, monitoring as code & team administration
Show reasoningHide reasoning
How this is scored
How the tool fits a team and a deployment pipeline: a documented REST API to create and read monitors, status pages and incidents, a Terraform provider, CLI or monitoring-as-code workflow, checks run from CI/CD before a deploy, bulk import of monitors, integrations with ticketing and chat tools, team members with roles, single sign-on (SAML) and SCIM, audit logs, several teams or client accounts in one organisation, white-label or client reporting for agencies, and two-factor authentication.
0 — No API, no team accounts; one login per account and monitors are set up only by hand.
3 — A web dashboard with a few team members; the API, roles and multi-client set-up are basic or not described.
5 — A documented REST API covering monitors and status pages, webhooks, team members with roles, two-factor authentication, bulk import or a CSV upload of monitors, and several projects, teams or client groups in one account.
8 — A Terraform provider or monitoring-as-code CLI with checks kept in version control, checks triggered from CI/CD, single sign-on (SAML), SCIM provisioning, audit logs, sub-accounts for clients with their own logins, and white-label client reports.
10 — Administration that scales across many teams and clients: every setting reachable by API and code with parity stated, granular roles per resource, SSO enforced with SCIM, audit logs exportable to a SIEM, and agency or reseller accounts with separate billing.
The Agency Developer
A REST API documented with a downloadable OpenAPI specification covers most of the control panel, can create and modify checks from scripts, and can pause or change the interval of many checks in one bulk call — genuinely useful when administering dozens of client sites at once. I found no public information on team roles, two-factor login, client sub-accounts with their own logins, white-label client reporting, or a Terraform or monitoring-as-code workflow. 1
The SaaS Platform Engineer
The REST API is genuinely well documented — version 3.1, a downloadable OpenAPI specification, bearer-token auth with read and read/write levels, and coverage of most control-panel functionality including bulk pause and resolution changes across checks, which is enough to script check lifecycle. I found no public information on a Terraform provider or other monitoring-as-code workflow, single sign-on, SCIM, audit logs, or team members with roles, and checks living in version control next to the service is a hard requirement for my team. 1
The Customer Support Lead
The REST API is documented in depth — tokens with read or read-write permission, a downloadable OpenAPI specification, bulk pausing and editing of checks, rate limits, and coverage of most of the control panel — which is genuine material for wiring checks into our deployment scripts. Team seats, member roles, single sign-on, audit logs and multi-client set-up are not described anywhere I read, so it stays below the middle. 1
The E-Commerce Operations Manager
The public API version 3.1 is genuinely well documented: RESTful and HTTPS-only, token authentication with read and read-write permission levels, a downloadable OpenAPI specification, documented rate limits, bulk pause and modification of multiple checks, and a stated aim of covering most of the control panel's functionality, plus a root-cause-analysis endpoint per check. We found no public information on team seats and roles, two-factor authentication, single sign-on, audit logs, client sub-accounts or monitoring-as-code workflows such as Terraform. 1
The Information Security Officer
A well-documented REST API with a downloadable OpenAPI specification covers most control-panel functionality, including bulk pausing and modification of checks, with tokens carrying read or read/write permission. We found no public information on single sign-on, SCIM provisioning, audit logs, team roles, two-factor authentication, or monitoring-as-code workflows — the controls I require before anyone gets a login. 1
The Skeptic
The API side is genuinely described: a REST API at version 3.1 covering most of the control panel, a downloadable OpenAPI specification, tokens with read or read-write levels, and a bulk call to pause or change resolution for many checks at once. We found no public information on monitoring-as-code, single sign-on, team roles, two-factor authentication or audit logs — the documented API is the only automation surface shown. 1
Uptime reports, data & the vendor's own reliability
Show reasoningHide reasoning
How this is scored
What the record is worth and whether the monitor itself can be trusted: uptime and SLA reports per monitor and period, response time charts and percentiles, scheduled reports by email, client-facing reports, how long check results and incident history are kept, export of results by CSV or API, the vendor's own public status page and incident history, its SLA, the probe IP addresses and user agent published for allow-listing, and an open-source or self-hosted edition.
0 — No history of any kind; only the current state is shown.
3 — An uptime percentage and a response time chart per monitor; retention, export and the vendor's own status are basic or not described.
5 — Uptime and response time reports per monitor and period, SLA reports, scheduled email reports, the retention period of check results stated, CSV or API export, the probe IPs published, and the vendor's own public status page.
8 — Response time percentiles and breakdowns (DNS, connect, TLS, first byte), client-ready branded reports, retention of a year or more stated per plan, a raw export of check results, the vendor's incident history and post-mortems public, and an SLA with credits published.
10 — A record that holds up in an audit: SLA calculations with their method stated, incident records suitable for ISO 27001, NIS2 or DORA evidence, full history exportable in an open format, a self-hosted or open-source edition with feature parity stated, and the vendor's own availability over several years published.
The Agency Developer
Some history is retrievable — the API returns the alerts generated for the account and the latest root cause analysis results per check. I found no public information on uptime or SLA reports, scheduled monthly reports I could send clients, retention periods, export of raw results, the vendor's own public status page or published probe IP addresses. 1
The SaaS Platform Engineer
The API returns per-check root cause analysis results and the account's alert history, so some per-check record exists. I found no public information on uptime or SLA reports, response-time percentiles, retention periods, raw export, the vendor's own status page, or published probe IP addresses for allow-listing. 1
The Customer Support Lead
Per-check root cause analysis results can be pulled through the API, and response times are measured closely enough to raise alerts. I found no public information on uptime percentages, response time charts, retention periods, export of history, probe addresses for allow-listing, or the vendor's own status page and SLA — for a contract renewal I need an uptime history I can point to, and nothing here provides one. 1
The E-Commerce Operations Manager
The API returns a list of past alerts for the account and the latest root-cause-analysis results per check, and response times are measured per check, but the captured documentation stops there. We found no public information on uptime or SLA reports, retention periods, export of results, published probe addresses, or the vendor's own status page and availability record — which is what I would need to show the agency what six hours of broken checkout cost us. 1
The Information Security Officer
The API returns root cause analysis results per check and the alerts generated for the account, which gives a partial incident trail, but we found no public information on uptime or SLA reports, retention periods, export formats, probe IP addresses for allow-listing, or the vendor's own availability record and SLA. 1
The Skeptic
The history the API exposes is per-check root cause analysis results, a list of alerts generated for the account, and a check overview. We found no public information on retention periods, CSV or raw export, probe IP addresses for allow-listing, or the vendor's own status page and incident record — a monitor whose own outages I cannot see is a monitor I cannot fully trust. 1
European sovereignty
panel opinion
n/r
n/r
n/r
n/r
n/r
Show reasoningHide reasoning
How this is scored
Who the contracting entity and the parent company are, where account data, alert contacts (names and phone numbers of the people on call), status page subscribers and check results are stored and processed, and who the subprocessors are (hosting, SMS and phone gateways, email delivery, support and payment tools). Independently sourced by the sovereignty pipeline. Probe locations outside Europe are part of what the product does and are not counted against it; where the data is stored and who processes it is. A self-hosted or open-source edition the customer runs on its own European servers counts as the customer's chain, whatever the vendor's seat.
0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and no data processing agreement offered.
3 — A privacy policy and a data processing agreement exist, but hosting location is unstated or non-EU and the subprocessors are not listed.
5 — EU hosting available and an EU contracting entity or EU representative, but parts of the chain (SMS and call gateways, email, support, payment) run through non-EU providers without a stated safeguard.
8 — EU hosting on named infrastructure, EU contracting entity, subprocessors listed with their locations, a data processing agreement published, and security certifications (ISO 27001, SOC 2) stated — or a self-hosted edition documented that keeps every record on the customer's own servers.
10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, or a self-hosted open-source edition with no call home, data export and deletion documented, and certifications published with their scope rather than implied.
The Agency Developer not rated — no public information
I found no public information on European sovereignty; the captured documentation says nothing about the contracting entity, where account data, on-call contacts or check results are stored, the subprocessors involved, or a data processing agreement. 1
The SaaS Platform Engineer not rated — no public information
The captured documentation says nothing about contracting entities, hosting locations, data residency, subprocessors, or a data processing agreement, and every sovereignty attribute is unknown rather than proven European or non-European. We found no public information on the data chain, so it stays unknown — something my Berlin company would have to resolve before contracting. 1
The Customer Support Lead not rated — no public information
Every sovereignty attribute — contracting entity, data residency, hosting, subprocessors, agreement, transfer mechanism — came back unknown, and I found no public information on any of them; the captured API documentation page says nothing about where data sits or who processes it. With nothing proved I report the criterion rather than score a guess. 1
The E-Commerce Operations Manager not rated — no public information
The captured API documentation says nothing about where account data, the names and phone numbers of our on-call people, subscribers or check results would be stored, who the subprocessors are for hosting, SMS or email, or any certifications. We found no public information on the contracting entity or data residency in what was captured. 1
The Information Security Officer
The captured vendor details identify SolarWinds Worldwide, LLC in the USA with an Irish affiliate mentioned in the privacy policy, but we found no public information on where account data, alert contacts and status subscribers are stored, on the subprocessor list, on a data processing agreement, or on security certifications. Until the on-call phone numbers and subscriber data have a documented chain, I cannot put them in the system. 1
The Skeptic not rated — no public information
Every sovereignty dimension is marked unknown, and the single captured page — API documentation — says nothing about the contracting entity's obligations, hosting location, data residency, subprocessors or a data processing agreement. We found no public information on any of this in what was captured. 1
Pricing transparency
not rated — the vendor publishes no price
Show reasoningHide reasoning
How this is scored
Whether a buyer can compute the real annual cost from public pages alone: price per tier by number of monitors, check interval and status pages, team seats and on-call responders, what SMS and phone alerts cost, which features (multi-step or browser checks, SSO, longer retention, private locations, white-label) cost extra, the free tier and its limits, overage handling, minimum term and VAT.
0 — No public prices at all; every customer is a sales call.
3 — A starting price or a free tier exists, but how cost scales with monitors, intervals, seats or alerts is unclear.
5 — Tiers are public with their monitor count, interval and main inclusions, but at least one commonly needed piece (SMS or call alerts, extra seats, extra status pages, SSO, longer retention) is unpriced or "on request".
8 — Every tier priced publicly with its scaling rule (monitors, interval, seats, responders, status pages), SMS and call costs stated, add-ons priced, overage handling stated, minimum term and VAT treatment stated.
10 — Complete price computability: annual cost derivable for a given number of monitors, interval, team size and alert volume, with every add-on, overage and support fee and the cancellation and data-return terms published.
The Agency Developer
The only pricing information is that response-time alerts are 'Not available for Starter and Free plans', which shows a free tier and a Starter tier exist. I found no public information on what any plan costs, how price scales with monitors, intervals or seats, or what SMS and phone alerts cost — at two hundred monitors I could not begin to budget from these pages. 1
The SaaS Platform Engineer
The only pricing information captured is that response-time down alerting is "Not available for Starter and Free plans", which confirms a free tier and a Starter plan exist and that features are gated by plan. I found no public prices, scaling rules by monitor count or interval, or stated SMS and call costs. 1
The Customer Support Lead
The documentation references Starter and Free plans, so a free tier exists, and one feature is explicitly reserved to paid tiers. No price figure, monitor count, seat cost or alert cost appears anywhere I read, so a buyer cannot begin to compute an annual cost from public pages captured here. 1
The E-Commerce Operations Manager
The only pricing information captured is that a response-time alert option is "Not available for Starter and Free plans", which confirms a Free and a Starter plan exist and that capabilities are gated by tier. We found no public information on any actual prices, scaling with monitors or intervals, SMS or call costs, overages, minimum term or VAT, so I cannot compute what monitoring across our March-to-June season would cost. 1
The Information Security Officer
The only pricing fact on the captured pages is that response-time alerts are not available for Starter and Free plans, which confirms a free tier and a starter tier exist. We found no public information on prices, monitor limits, seat costs, SMS and call charges, overage handling, contract terms or VAT. 1
The Skeptic
The only pricing signal on the captured pages is a parenthetical note that response-time threshold alerts are "Not available for Starter and Free plans" — so a free tier and a Starter plan exist. We found no public information on any price, scaling rule, seat or responder cost, SMS or call rates, or contract terms, so no annual cost can be computed from the capture. 1
European sovereignty — proven facts
0 of 6 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined | — | uncited Report an error |
|---|---|---|---|
| Hosting location | Not determined | — | uncited Report an error |
| Hosting options | Not determined | — | uncited Report an error |
| Open source | Not determined | — | uncited Report an error |
| Data processing agreement | Not determined | — | uncited Report an error |
| Transfer impact assessment | Not determined | — | uncited Report an error |
Questions about Pingdom
Is Pingdom European?
No. whats-best.ai classifies Pingdom as Rest of world.
Where does Pingdom store data?
Not stated on the vendor’s pages as of 1 Nov 2026.
Does Pingdom have a free plan?
Not stated on the vendor’s pages as of 1 Nov 2026.
What are the best alternatives to Pingdom?
As of 2 Nov 2026, the panel rates Hyperping (3.5/5), Checkly (3.5/5) and openstatus (3.5/5) highest among the other 14 Uptime Monitoring & Status Pages products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is Hyperping (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: Pingdom alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 1 Nov 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- We found no public information on compliance on the pages we read (docs.pingdom.com/api). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- 15 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 4 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 data facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
Sources (1)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 API documentation docs.pingdom.com Checked 1 Nov 2026 Details →