Synthetic Monitoring

Simulate visitor interaction with your site to monitor the end user experience.

View Product Info


Simulate visitor interaction

Identify bottlenecks and speed up your website.

Learn More

Real User Monitoring

Enhance your site performance with data from actual site visitors

View Product Info


Real user insights in real time

Know how your site or web app is performing with real user insights

Learn More

Infrastructure Monitoring Powered by SolarWinds AppOptics

Instant visibility into servers, virtual hosts, and containerized environments

View Infrastructure Monitoring Info
Comprehensive set of turnkey infrastructure integrations

Including dozens of AWS and Azure services, container orchestrations like Docker and Kubernetes, and more 

Learn More

Application Performance Monitoring Powered by SolarWinds AppOptics

Comprehensive, full-stack visibility, and troubleshooting

View Application Performance Monitoring Info
Complete visibility into application issues

Pinpoint the root cause down to a poor-performing line of code

Learn More

Log Management and Analytics Powered by SolarWinds Loggly

Integrated, cost-effective, hosted, and scalable full-stack, multi-source log management

 View Log Management and Analytics Info
Collect, search, and analyze log data

Quickly jump into the relevant logs to accelerate troubleshooting

Learn More

New grouping of monitoring servers

PingdomAs you’re probably aware, Pingdom has been growing a lot over the past couple of years, and as more and more users have joined our service, our infrastructure has grown as well. Our monitoring network now consists of 40 locations that test your sites and servers.

Starting this week, we’re going to change how these monitoring locations monitor your sites. It’s not something most of you will notice, monitoring will be as reliable as ever, but we thought it was worth a blog post explaining what we’re doing and why to avoid any potential confusion.

How monitoring has worked until now

The way it has worked until now, tests of a site have been rotated through all our monitoring locations.

In other words, assuming today’s 40 locations and 1-minute monitoring, each location tests your site once every 40 minutes. If you use 5-minute monitoring, that gets spread out even more, each location testing your site once every 200 minutes (3h 20m).

The problem with our historical approach

As you can imagine, one problem with this is that it makes it increasingly difficult to see trends per location as our monitoring network grows. With a bigger network, each location tests your site more seldom. And we keep adding more locations.

This would be fine if all we cared about was pure uptime monitoring, i.e. testing if a site works or not. But we also care about trends, including performance trends.

In short, our old approach doesn’t scale in the long term, and Pingdom will have many more monitoring locations. We’re already getting too big for our old approach.

That’s why we’re now making a change.

New approach, grouping our monitoring servers

We’re going to start grouping our monitoring servers into slightly smaller groups (subsets) that will each act as a separate monitoring network. Each site or server monitored by Pingdom will be monitored from one of these groups. It will all be handled automatically, there are no settings our users have to worry about.

The locations in each group are still geographically dispersed, but now any “trend tracking” you do will be more precise, since each location will test your site more frequently.

It’s also worth pointing out that there are still enough locations in each group that monitoring reliability will not suffer at all.

Initially we’re grouping our existing 40 locations into 4 groups of 10 monitoring locations each (the exact numbers aren’t important, and will grow and change over time). Just as today, each group contains a mix of locations from North America and Europe.

Added bonus & final words

An added bonus is that it now also becomes easier for you to filter by location (for example in the response time report) since you don’t have to wade through quite as many locations. And when you do select a location, since tests are performed more often by each location, your results will have a higher resolution.

This location grouping also has some nice benefits on Pingdom’s backend and the way we aggregate data, which will help us introduce some pretty cool new features in the future. We can’t tell you about these plans quite yet, but they’re coming.

As we said in the beginning, most of you won’t notice anything at all since this is a “behind-the-scenes” change, but we like keeping you guys posted on what’s going on.

And as always, if you have any questions whatsoever, please don’t hesitate to get in touch with our support (support (at)

Webpages Are Getting Larger Every Year, and Here’s Why it Matters

Last updated: February 29, 2024 Average size of a webpage matters because it [...]

A Beginner’s Guide to Using CDNs

Last updated: February 28, 2024 Websites have become larger and more complex [...]

The Five Most Common HTTP Errors According to Google

Last updated: February 28, 2024 Sometimes when you try to visit a web page, [...]

Page Load Time vs. Response Time – What Is the Difference?

Last updated: February 28, 2024 Page load time and response time are key met [...]

Can gzip Compression Really Improve Web Performance?

Last updated: February 26, 2024 The size of the web is slowly growing. Over [...]

Monitor your website’s uptime and performance

With Pingdom's website monitoring you are always the first to know when your site is in trouble, and as a result you are making the Internet faster and more reliable. Nice, huh?



Gain availability and performance insights with Pingdom – a comprehensive web application performance and digital experience monitoring tool.

Start monitoring for free