Uptime monitoring, transaction checks, and why your site can be “up” and still failing users.
Pingdom has monitored uptime since 2007. AuditJet monitors the quality layer Pingdom was never built for: Core Web Vitals, performance regressions, revenue impact, and AI-generated fix guidance. This page explains how uptime monitoring works, what it catches, what it misses, and when you need both.
Background
What is Pingdom?
Pingdom is a website monitoring service that originated in Västerås, Sweden in 2007. It was one of the first SaaS tools to make uptime monitoring accessible outside of large enterprise IT departments — before Pingdom, knowing whether your website was down often meant waiting for a user complaint or stumbling onto the problem yourself. Pingdom was acquired by SolarWinds in 2014 and has since become one of the most widely recognised names in the uptime monitoring space.
Its core value proposition is simple and powerful: know immediately when your site goes down so you can fix it fast. Every minute of unplanned downtime has a measurable cost. For e-commerce sites, that cost is lost orders. For SaaS products, it is churning users. For media companies, it is lost advertising impressions. Teams without monitoring discover outages from customer complaints, support tickets, or social media — often twenty minutes or more after the problem began. Pingdom closes that gap.
The primary users are sysadmins, DevOps engineers, IT teams, and small business owners who need a reliable safety net: a tool that watches their site around the clock and calls, texts, or Slacks the right person the moment something stops responding. Pingdom is deliberately approachable — basic uptime monitoring can be set up in under five minutes with no technical expertise required.
Over the years Pingdom expanded beyond simple uptime checks. It now offers transaction monitoring (scripting multi-step user flows), page speed testing, Real User Monitoring via a JavaScript snippet, and public status pages. But its heritage and its strongest suit remain uptime: the confidence that if your server stops responding, your team will know within minutes.
That heritage also defines its limitations. Pingdom was designed to answer one question — is the site up? — and the rest of its feature set has been built around that original question. Concepts like Core Web Vitals, Lighthouse-based performance scoring, or revenue impact modelling are outside its original scope. Understanding where Pingdom excels and where it reaches its boundary is the starting point for deciding whether you need it, something else, or both.
How it works
How uptime monitoring works
At its core, an uptime monitor does something conceptually simple: it sends an HTTP request to your URL on a fixed schedule and checks whether a response comes back. But the details matter enormously for how reliable and useful that monitoring actually is.
HTTP checks
An HTTP check asks a single question: did the server respond? Pingdom sends a GET request to your URL from one or more monitoring locations — data centres distributed around the world. If the server returns an HTTP 2xx status code (200 OK, 201 Created, etc.) within a timeout period, the check passes. If the server returns a 4xx or 5xx error, times out, or refuses the connection, the check fails and an alert fires.
This is deliberately minimal. It is not testing whether your page rendered usefully, whether images loaded, or whether interactive elements are functional. It is asking: did the TCP connection succeed, did HTTP headers arrive, did the status code indicate success? A server that returns a blank 200 page with a JavaScript error will pass this check every time.
Check intervals and the alerting tradeoff
Most uptime tools let you choose how frequently checks run — typically between one minute and five minutes. The tradeoff is direct: more frequent checks mean faster outage detection but higher cost (both in compute resources for the monitoring service and in pricing to you). A one-minute check interval means you will be alerted within about one minute of an outage beginning. A five-minute interval means a site could be completely down for up to five minutes before your team gets the first alert — and potentially another five before a second confirmation.
Most production teams running critical e-commerce or SaaS applications use one-minute checks on their most important URLs. Lower-traffic or lower-stakes pages might use five-minute checks to reduce noise and cost.
SSL certificate monitoring
An expired SSL certificate is functionally equivalent to downtime. Modern browsers display full-page warnings blocking users from proceeding when a certificate has expired or been misconfigured. Pingdom can monitor your certificate expiry date and alert you in advance — typically 30, 14, and 7 days before expiry — so you can renew before the warning ever reaches users. This is a straightforward but high-value feature: certificate expiry is an entirely preventable outage that still catches teams off guard with surprising regularity.
Transaction (synthetic) monitoring
HTTP checks tell you whether a server responds. Transaction monitoring tells you whether a user can actually accomplish something. A transaction monitor scripts a multi-step user journey — opening a product page, adding an item to the cart, entering an address, completing a payment — and verifies that every step succeeds. If the checkout button is broken due to a JavaScript error, the cart session fails to persist, or the payment processor returns an error, the transaction monitor catches it even though the page itself returns HTTP 200 on every request.
For e-commerce teams, transaction monitoring on the checkout flow is one of the highest-value things they can run. A broken checkout that goes undetected for two hours on a Friday evening can cost more than any planned maintenance window.
Real User Monitoring (RUM)
Pingdom also offers basic Real User Monitoring via a JavaScript snippet you embed on your pages. RUM collects performance timings — page load duration, browser type, country of origin — from actual visitors as they use your site. This is philosophically different from uptime checks: instead of a synthetic probe run on a schedule, you are collecting real telemetry from real people on real devices.
Pingdom's RUM is relatively basic — it captures load times and visitor geography but does not provide the Core Web Vitals granularity (LCP, INP, CLS) that modern performance optimisation requires. Dedicated RUM tools go considerably deeper.
Alert fatigue
A common failure mode in uptime monitoring is alert fatigue: a monitoring setup generates so many alerts — many of them transient, false-positive, or low-priority — that the team begins ignoring them. Good uptime monitoring requires tuning. Single-location checks are more prone to false positives (one probe having a network hiccup) than multi-location checks that require agreement from multiple probes before alerting. Configuring appropriate escalation paths — a Slack message for a single failed check, a phone call for a confirmed outage — keeps alerts meaningful.
Features
Key features of Pingdom
Uptime monitoring from 100+ locations
Pingdom operates a global network of more than 100 probe servers — physical locations distributed across North America, Europe, Asia-Pacific, South America, and the Middle East. When you configure a check, you can select which probe locations to use.
Multiple locations matter because a server can be down in one region while still serving requests normally in another. Regional outages are common: a CDN misconfiguration might knock out US-East while EU users are unaffected. A database failover might cause elevated error rates in one availability zone. Monitoring from a single location gives you a narrow view; monitoring from a dozen gives you a map.
Pingdom typically requires a configured number of locations to confirm a failure before alerting — reducing false positives from individual probe instability. A single probe timing out is a network hiccup; five probes across three continents all failing is an outage.
Transaction (synthetic) monitoring in practice
Pingdom's transaction monitoring uses a recorder and a scriptable browser-based runner. A DevOps engineer or QA team member records a user journey — for example, a full e-commerce checkout from product page to confirmation screen — and Pingdom replays that journey from multiple locations on a schedule.
Consider what a well-configured transaction monitor actually catches for an e-commerce team: a promotional code field that stops accepting input after a React re-render; an address validation API that starts returning 500 errors; a payment processor integration that breaks after a dependency update. None of these would appear in a basic HTTP uptime check, because every individual page still returns 200. Transaction monitoring is the bridge between “the server is responding” and “users can actually complete the thing they came to do.”
Transaction monitors are more expensive to set up and maintain than simple HTTP checks — the scripts need to be updated whenever the UI changes — but for critical revenue flows they are among the highest-value monitoring investments a team can make.
Page speed monitoring
Separate from uptime checks, Pingdom offers a Page Speed feature that loads your page in a controlled browser and measures how long it takes. You get waterfall charts showing every resource the page loaded, timing breakdowns, and a summary score.
It is important to understand what this feature does and does not measure. Pingdom's page speed testing captures overall load time and resource-level timing, but it is not a Lighthouse audit and does not directly report Google's Core Web Vitals — LCP, INP, and CLS — with the specificity that SEO and conversion optimisation work demands. It will not tell you your LCP element, your CLS score over time, or your INP percentile. If improving your Google Search ranking or specifically optimising for conversion-impacting performance metrics is the goal, Pingdom's page speed feature is a starting point rather than a comprehensive answer.
Public status pages
Pingdom lets you create a public-facing status page — a URL you can share with customers, at status.yourcompany.com or similar — that displays the current and historical uptime of your services. Status pages serve a communication function: when something goes wrong, customers check the status page rather than flooding your support inbox. When something goes right consistently, the status page builds trust.
This is a genuinely useful customer-facing feature, particularly for SaaS companies and APIs whose customers integrate deeply with their availability. Many enterprise procurement processes now ask vendors to link their status pages as part of due diligence.
Alerting integrations
Pingdom integrates with the major on-call and incident management workflows: SMS, email, phone calls, Slack, PagerDuty, OpsGenie, and webhooks for custom integrations. Escalation policies can be configured so a first alert goes to Slack, a second (if unacknowledged) goes to PagerDuty which pages the on-call engineer, and a third escalates to the team lead. This integration depth is what makes Pingdom a professional-grade tool rather than a simple notification script — it fits into the incident response workflows that engineering teams already operate.
Honest assessment
Pingdom: strengths and limitations
Genuine strengths
Reliable, proven uptime monitoring with 15+ years of track record and a global probe network trusted by tens of thousands of teams.
Easy to set up — basic uptime monitoring is live in under five minutes with no technical expertise required.
Transaction monitoring is genuinely valuable for critical user flows: checkout, login, subscription, onboarding. It catches broken flows that HTTP checks miss.
Public status pages are a professional customer-facing feature that reduces support load during incidents and builds trust when things run smoothly.
Deep alerting integrations with PagerDuty, OpsGenie, and Slack fit naturally into professional on-call and incident response workflows.
Honest limitations
Page speed monitoring does not track Core Web Vitals (LCP, INP, CLS) specifically — you cannot get Pingdom to alert you when your LCP degrades past Google's 2.5s threshold.
No performance regression detection tied to deploys — Pingdom does not tell you that your LCP was 1.8s on Monday and is now 3.4s on Thursday, or why.
No AI fix guidance — when something is slow or broken, Pingdom tells you the symptom, not how to fix it in code.
No competitor benchmarking — you cannot compare your performance against a competitor's site in the same tool.
RUM is basic compared to dedicated real-user monitoring tools — no Core Web Vitals breakdown, no element-level attribution.
Fundamentally focused on 'is it up?' not 'is it fast, healthy, and earning?' — the quality layer of performance optimisation is outside its design scope.
The key insight
The uptime vs user experience gap
The most important thing to understand about uptime monitoring — and this is the insight that motivates everything else on this page — is that a site can have perfect uptime and still be silently losing users and revenue.
Google's research is consistent and well-documented: page speed directly affects user behaviour and conversion rates. The Core Web Vitals threshold for a “Good” Largest Contentful Paint is 2.5 seconds. A site that loads its main content in 4 seconds is within Pingdom's definition of “up” — the server responded, the page loaded, no errors — but research from Google and Deloitte suggests that a shift from a 1s load to a 3s load can increase bounce rates by as much as 32%. That is roughly 20–30% of potential conversions evaporating silently, without a single alert firing.
HTTP response codes are not a proxy for user experience. A 200 OK tells you the server accepted the request and sent a response. It tells you nothing about whether the Largest Contentful Paint element — the hero image, the main product photo, the above-the-fold headline — appeared in under 2.5 seconds. It says nothing about whether the layout shifted three times as JavaScript loaded, pushing the add-to-cart button down the page and generating a CLS score that Google penalises. It does not capture whether the first interactive element responded to a user's tap within 200ms.
A real scenario uptime monitoring cannot catch
A JavaScript error introduced in a deploy breaks the checkout button on mobile devices. The page loads normally on desktop browsers and returns HTTP 200 from every Pingdom probe location. But 60% of your traffic is on mobile. For those users, the checkout button does nothing. Pingdom stays green. Transactions drop. You find out from a customer complaint four hours later.
This is not a hypothetical — it is a class of failure that happens routinely in production and is completely invisible to uptime monitoring. Transaction monitoring on the mobile checkout flow would have caught it within minutes.
Performance is the invisible downtime. It does not trigger alerts. It does not appear on status pages. It erodes revenue gradually and quietly — sometimes after a deploy, sometimes after a third-party script gets heavier, sometimes as cumulative technical debt in a render-blocking resource chain. The gap between “the server is up” and “the user experience is good” is where Core Web Vitals monitoring lives — and it is a gap that Pingdom, by design, does not cover.
Honest comparison
AuditJet vs Pingdom
The most useful framing here is not competition. Pingdom and AuditJet occupy different layers of the monitoring stack and answer different questions. Treating them as alternatives is like treating a smoke alarm and a carbon monoxide detector as alternatives: they detect different threats, and having one does not substitute for the other.
Pingdom monitors availability. AuditJet monitors quality. Pingdom fires when the site is down or a transaction fails. AuditJet fires when the site is slow, degrading, losing Google rankings, or costing you conversions — even when Pingdom shows everything green.
| Capability | AuditJet | Pingdom |
|---|---|---|
| Uptime monitoring | Not the primary use case — pair with an uptime tool for complete coverage. | Core feature: multi-location HTTP checks every minute with on-call alerting. |
| Transaction monitoring | Not available — use Pingdom for critical user flow monitoring. | Available: script multi-step user journeys and alert on failures. |
| SSL certificate alerts | Not available. | Available: alert before certificate expiry. |
| Core Web Vitals (LCP, INP, CLS) | Hourly Lighthouse-based tracking of all three CWV metrics with trend history and regression alerts. | Not tracked specifically — page speed metrics available but not CWV-aligned. |
| Performance regression detection | Automated alerts when CWV scores degrade relative to baseline, with before/after comparison. | Not available. |
| Revenue impact estimates | Connects CWV regressions to estimated conversion and revenue impact. | Not available. |
| AI Fix Blueprints | Code-level fix guidance per performance issue, generated from audit data (Watchdog+). | Not available. |
| Competitor benchmarking | Monitor competitor CWV scores on the same schedule (Pro+). | Not available. |
| Public status pages | Not available. | Available: customer-facing service status page. |
| On-call integrations | Slack, email, and webhook alerting. | SMS, phone, email, Slack, PagerDuty, OpsGenie. |
Where Pingdom wins
Real-time downtime alerting, transaction monitoring for critical user flows, SSL certificate expiry warnings, public status pages, and deep on-call integrations with PagerDuty and OpsGenie. If you need to know the moment your checkout breaks or your server goes dark, Pingdom is a mature, proven answer. Its 15+ year track record and simple setup make it the default choice for uptime alerting.
Where AuditJet wins
Core Web Vitals tracking (LCP, INP, CLS) with hourly scan cadence, automated performance regression detection tied to score baselines, revenue impact modelling that connects a 0.8-point LCP regression to an estimated conversion loss, AI-generated fix blueprints with code-level guidance, and competitor benchmarking. If your site is up but your Lighthouse scores are quietly degrading, your SEO rankings are slipping, or you need to justify a performance engineering sprint to stakeholders, AuditJet surfaces the data that Pingdom cannot.
Together
The complete picture: Pingdom fires when the site is down or a user flow is broken. AuditJet fires when the site is slow, degraded, or silently losing you money. Running both gives you a monitoring stack that covers availability at the bottom and quality at the top — the two layers that together determine whether users can reach your site and whether it is worth staying on when they do.
Decision guide
Who should use each?
Use Pingdom if…
- You need real-time alerting the moment your site stops responding.
- You want to monitor critical user flows (checkout, login, signup) for silent breakage.
- You need SSL certificate expiry warnings before they reach users.
- A public status page is part of your customer communication plan.
- Your on-call workflow uses PagerDuty or OpsGenie and you need deep integration.
Use AuditJet if…
- You need to track LCP, INP, and CLS specifically — not just page load time.
- You want automated alerts when a deploy degrades Core Web Vitals.
- You need revenue impact context to prioritise performance work.
- You want AI-generated, code-level fix guidance rather than a score.
- You want to benchmark your CWV scores against direct competitors.
Use both if…
- You want complete coverage of availability AND quality.
- You run an e-commerce site where both downtime and slow LCP cost revenue.
- Your team has separated on-call (availability) from performance engineering (quality).
- You want Pingdom watching for outages while AuditJet watches for silent degradation.
- You care about Google rankings — CWV affects organic search position.
Common questions
Frequently asked questions
What is uptime monitoring?
Uptime monitoring is the practice of automatically and repeatedly checking whether a website or server is reachable and responding correctly. A monitoring service sends HTTP requests to your URL from one or more locations on a set interval — commonly every one to five minutes — and alerts you if the server fails to respond, responds too slowly, or returns an error status code. The goal is to minimise the time between a site going down and your team knowing about it.
What is the difference between uptime monitoring and performance monitoring?
Uptime monitoring answers the binary question: is the server responding? Performance monitoring answers a richer set of questions: how fast does the page load, how does it feel to a real user, are Core Web Vitals within Google's thresholds, and is performance getting better or worse over time? A site can pass every uptime check — returning HTTP 200 in under 200ms — while still loading so slowly that 30% of visitors abandon before the page renders. Performance monitoring catches the failures that uptime monitoring cannot see.
Does Pingdom measure Core Web Vitals?
Pingdom offers a Page Speed feature that measures load time and some synthetic performance metrics, but it does not track Google's Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — with the depth, frequency, or regression alerting that SEO and conversion optimisation requires. AuditJet runs hourly Lighthouse-based scans tracking all three CWV metrics with trend history and automated regression alerts.
Can AuditJet replace Pingdom?
No — and it is not designed to. AuditJet is a Core Web Vitals and performance quality monitor, not an uptime monitor. It does not send pings every minute to check whether your server is responding. If you need real-time downtime alerting, transaction monitoring, or SSL expiry warnings, keep Pingdom or a similar tool. AuditJet handles the quality layer: CWV monitoring, regression alerting, revenue impact estimates, and AI fix guidance. The two tools are complementary.
What is transaction monitoring?
Transaction monitoring (sometimes called synthetic monitoring) goes beyond a simple HTTP check by scripting a multi-step user journey — for example, landing on a product page, adding an item to the cart, entering payment details, and completing a checkout. The monitor runs this script on a schedule and alerts you if any step fails or takes too long. This catches broken user flows that a basic uptime check would completely miss, because the page might return HTTP 200 while a JavaScript error silently prevents the checkout button from working.
Why is my site 'up' but still slow?
Uptime monitoring measures whether a server responds — typically just the time-to-first-byte of the initial HTTP response. It does not measure how long it takes for the page to become visually complete or interactive. A server can return its first byte in 80ms (passing every uptime check) while the browser spends another four seconds downloading JavaScript bundles, rendering above-the-fold content, and stabilising layout. From a user perspective the page is slow, but from an uptime monitor's perspective the server is healthy. This is the gap between server availability and user experience.
How does AuditJet detect performance regressions?
AuditJet runs automated Lighthouse audits on your pages hourly and maintains a rolling score history for each Core Web Vitals metric. When a metric crosses a configurable threshold relative to its recent baseline — for example, LCP degrades from 1.8s to 3.2s after a deploy — AuditJet fires an alert with the before/after comparison, a revenue impact estimate, and an AI-generated fix blueprint identifying likely root causes in your code.
What is the difference between synthetic and real-user monitoring?
Synthetic monitoring runs scripted tests from controlled lab conditions on a fixed schedule — the same machine, same network, same browser every time. It gives you consistent, comparable measurements and catches regressions immediately after a deploy. Real-user monitoring (RUM) collects performance data from actual visitors in the wild: their real devices, real network conditions, and real geographic locations. Synthetic data is more reproducible and actionable for debugging; RUM data reflects what real users actually experience. The two are complementary — synthetic catches regressions early, RUM validates the fix landed for real users.
Complete monitoring coverage
Uptime is the floor. Performance is the ceiling.
Use Pingdom to know when your site goes down. Use AuditJet to know when it's slow, degraded, or costing you conversions — before a single user complains.