An uptime check answers a narrow but important question: can an external probe reach the endpoint you care about and receive the response you expect? Pingdom can perform this test repeatedly from its probe infrastructure and alert you when the check is considered down.
This tutorial focuses on a basic HTTP(S) uptime check. It explains how to choose the URL, interval, probe region, optional request behavior, and alert recipients; how to use Test Check before saving; and how to diagnose cases where Pingdom reports a failure while the site appears healthy in your browser.
Last verified: September 10, 2026. SolarWinds documentation notes that navigation can differ when the APM Integrated Experience is enabled. Treat the menu paths below as documented routes, not as a guarantee that every account has identical navigation.
What You'll Accomplish
You will create a Pingdom uptime check that:
- monitors one clearly defined HTTP or HTTPS endpoint;
- uses a check interval and probe region chosen for an operational reason;
- validates the URL before the check is saved;
- routes alerts to the intended recipients;
- produces check history you can inspect; and
- has a troubleshooting plan for redirects, authentication, DNS/TLS, probe blocking, and slow responses.
Prerequisites
You need:
- a Pingdom account with permission to create uptime checks;
- a public website, API health URL, or other HTTP(S) endpoint;
- a clear expectation for what the endpoint should return;
- an alert contact, user, or team if notifications are required; and
- permission to create a temporary test check for controlled validation.
If a URL is reachable only from your internal network, a public Pingdom probe will not magically gain access to it. Decide whether the endpoint should be public to Pingdom before creating the check.
Quick Answer
In My Pingdom, use Add uptime check from the dashboard or go to the documented Monitoring → Uptime area and add a new check. Choose HTTP(S), give the check a descriptive name, select the interval, enter the URL, choose the relevant probe region, and configure alert recipients. Before creating the check, use Test Check to catch URL or connectivity mistakes. After saving, verify that recent check history is healthy. If Pingdom reports downtime unexpectedly, compare the exact HTTP response with what a browser does, then inspect redirects, Basic Auth, custom headers, TLS, DNS, probe-region behavior, and security rules that may block synthetic traffic.
Step 1: Choose the Endpoint Based on the Failure You Want to Detect
Do not start with the Pingdom form. Start with the monitoring question.
For a public website, you may want to know:
"Can a user reach the public HTTPS endpoint?"
For an application, a better question may be:
"Can an external client reach the readiness endpoint and receive a successful response?"
Those questions can point to different URLs.
Homepage or health endpoint?
A homepage includes more of the public delivery chain: DNS, CDN, TLS, load balancer, reverse proxy, and application routing. That makes it useful for user-facing availability.
A health endpoint can be more deterministic and easier to diagnose. However, a poorly designed health endpoint can remain green while the user journey is broken.
The best first check is the simplest endpoint whose failure would mean something actionable.
Step 2: Open the Uptime Check Form
SolarWinds currently documents two ways to add an uptime check:
- use Add uptime check from the Pingdom dashboard; or
- navigate to the Uptime monitoring area and add a new check.
Some official pages describe the route as Monitoring → Uptime. The Pingdom Getting Started Guide warns that accounts using the APM Integrated Experience can have different navigation.
If your menu does not match the screenshots or labels in an older-looking documentation page, search for the Uptime product area rather than forcing the historical path.
This distinction matters because Pingdom documentation has existed for many years. A technically correct check configuration should not depend on an obsolete screenshot.
Step 3: Name the Check and Select an Interval
Give the check an operational name such as:
Customer portal - HTTPS availability
A useful name tells a responder:
- which service is affected;
- which endpoint class is being checked; and
- why the check exists.
Avoid Pingdom check 1 or Website.
Check interval
The current Pingdom Getting Started Guide states that a basic check interval can range from once per minute to once per hour and recommends one minute in its example.
Do not treat one minute as a universal requirement. Choose the interval from:
- how quickly the service needs failure detection;
- how much transient failure you are willing to observe;
- the importance of the endpoint; and
- the behavior of your alerting rules.
A one-minute interval does not guarantee that a human will be notified exactly one minute after a failure. Pingdom's alert configuration and failure-confirmation behavior also influence when a notification is sent.
Step 4: Choose HTTP(S) and Enter the URL
For normal website availability, choose HTTP(S).
Enter the complete endpoint you intend to monitor and make the HTTP/HTTPS choice explicit. For a production website, HTTPS is normally the user-facing path.
Pingdom's current documentation describes the basic HTTP check as a request that retrieves the page response; it does not behave like a full browser loading every image and executing all client-side JavaScript.
That has an important consequence:
A green uptime check does not prove that an entire JavaScript application works.
If you need to prove that a login, search, checkout, or other browser workflow works, use a transaction check instead.
Check the final URL carefully
Common mistakes include:
- monitoring
http://when the supported endpoint is HTTPS; - using a retired path;
- monitoring an origin rather than the public CDN hostname;
- choosing a URL that requires a session cookie; or
- monitoring a page that intentionally redirects to another domain.
Use Test Check later to catch these problems before the check starts alerting.
Step 5: Choose the Probe Region
Pingdom's getting-started documentation describes selectable test locations/regions, with North America and Europe used by default in the documented example and other regions available depending on the feature/account.
Choose a region that reflects your users or your troubleshooting objective.
If most customers are in Europe, a European external check is more representative than testing only from North America. If a service is global, one region can be a starting point, but it does not prove every geography is healthy.
Avoid adding many locations solely to create more data. Each location should answer a useful availability question.
Step 6: Configure Optional Request Behavior Only When Needed
The detailed HTTP check documentation includes options such as:
- Basic Auth username/password;
- content/string checking;
- POST data;
- custom request headers;
- SSL/TLS certificate validation/expiration alerts;
- IPv6 checks; and
- port settings.
Do not enable these by default.
Basic authentication
Pingdom's HTTP check can use Basic Auth. That is not the same as logging into a web application through a form.
If your availability test depends on a form login or browser session, a simple HTTP check is the wrong abstraction.
Use dedicated least-privilege credentials when authentication is necessary. Never expose real credentials in screenshots, source code, or public documentation.
Custom headers
Headers can be useful for:
- a dedicated monitoring token;
- a required Host or application header;
- a custom User-Agent; or
- an API content type.
Keep monitoring credentials separate from employee credentials and rotate them normally.
String checks
A string check can catch a situation where the server returns a successful HTTP response but the body is clearly wrong. Use a stable marker, not marketing copy that changes during routine content edits.
If you need several browser-level assertions, use transaction monitoring rather than turning one uptime check into a brittle pseudo-browser test.
Step 7: Configure Alerting Deliberately
Pingdom lets you select who should be alerted when a check is considered down. Its documentation also describes settings that affect alert timing and re-alerting.
Before enabling notifications, decide:
- who owns the service;
- which channel is appropriate;
- how quickly a failure should page somebody;
- whether recovery notifications are useful; and
- what context should accompany the alert.
A good alert tells a responder enough to start triage. Add a short runbook or service context where the product supports it.
Do not route a new unvalidated check to the entire production team. First prove that its success condition is stable.
Step 8: Run Test Check Before Saving
The Getting Started Guide explicitly tells users to click Test Check before creating the check.
Use it.
A successful Test Check helps validate:
- the URL is correct;
- the endpoint is reachable from Pingdom;
- the selected protocol/port is sensible; and
- basic request settings are accepted.
A failed Test Check is useful too. It gives you an opportunity to fix the configuration before the monitor begins creating operational noise.
Do not interpret one successful test as proof that uptime is reliable. It validates the configuration at that moment; ongoing checks provide the time-series evidence.
Step 9: Create the Check and Inspect Live History
After a successful test, create the uptime check.
Then wait for multiple scheduled checks and confirm:
- the check appears in the expected Uptime area;
- its state is healthy;
- timestamps are current;
- response times are plausible; and
- no unexpected alerts or regional failures appear.
If your account uses a different navigation because of the Integrated Experience, the exact menu labels may differ, but you should still be able to identify the check and its latest results.
Verify the Setup
Consider the setup complete only if all of these are true:
- the check monitors the intended production/test URL;
- the HTTP/HTTPS protocol is correct;
- the probe region represents the intended audience or use case;
- Test Check passes;
- multiple live checks have succeeded;
- the intended contact/team is attached;
- responders know what the check represents; and
- you have a safe way to validate an incident.
Test failure behavior without breaking production
Create a temporary check against a controlled endpoint that you can make fail, or temporarily configure a non-production URL with a known bad response.
Route this check only to a test-safe recipient.
Observe how Pingdom reports the failure and how the alert arrives. Then restore or delete the test resource.
Do not deliberately break the production website merely to prove uptime monitoring works. This tutorial describes a validation method; it does not claim PerfMonitoring executed a live test in your Pingdom account.
Common Problems and Fixes
Problem: Pingdom is down but the site works in my browser
Possible cause: your browser follows redirects, sends cookies, loads from a different network, or is treated differently by security controls.
Fix: reproduce the request without browser state. Inspect the status, redirect chain, DNS answer, TLS handshake, and server/WAF logs around the Pingdom check time.
Problem: A Basic Auth site fails
Possible cause: the check credentials are missing or incorrect, or the site uses form-based authentication rather than HTTP Basic Auth.
Fix: confirm the authentication mechanism. Configure Basic Auth only for actual HTTP Basic Auth. Use transaction monitoring for browser-form workflows.
Problem: The check fails after a redirect change
Possible cause: the monitored endpoint now redirects unexpectedly or points to an unavailable destination.
Fix: inspect the full redirect chain. Decide whether the canonical target should be monitored directly. Treat a surprising redirect as a possible application/configuration failure rather than automatically hiding it.
Problem: Pingdom gets blocked by a WAF or bot rule
Possible cause: the synthetic request is classified as automated traffic or comes from an address/range your security layer restricts.
Fix: verify the block in WAF/server logs first. Use Pingdom's current probe-server/network documentation to create a narrowly scoped allow rule if appropriate. Do not disable bot or firewall protection globally.
Problem: The check is slow from one region
Possible cause: geographic routing, DNS, CDN, origin latency, or network path differs by region.
Fix: compare the affected region with other external checks and with server/CDN telemetry. A regional failure can be real even when your local browser is fast.
Problem: A check reports down because a string changed
Possible cause: the string assertion is tied to content that was edited, translated, or personalized.
Fix: use a stable machine-oriented marker or health endpoint. Monitoring should not depend on a marketing headline unless that exact text is the business requirement.
Problem: Alerts arrive too quickly or too often
Possible cause: alert timing is stricter than the service's tolerance, or the check itself is unstable.
Fix: diagnose the signal first. Then adjust alert confirmation/re-notification behavior to match the response objective. Do not use long delays to conceal an unhealthy endpoint.
Best Practices
Use one check for one operational statement
"HTTPS endpoint returns an acceptable response" is clear. "Homepage, login, API, certificate, checkout, and content are all okay" is too much for one basic uptime check.
Test externally meaningful dependencies
Monitor the public hostname when the CDN/DNS/TLS path matters to users. Monitor an internal component separately if it has a different owner and remediation path.
Keep authentication narrow
Synthetic-monitor credentials should be dedicated, minimally privileged, and easy to rotate.
Treat uptime and browser functionality as different signals
A simple HTTP check proves reachability and response behavior. It does not execute your complete front-end application. Use transaction monitoring for multi-step browser behavior.
Review checks after architecture changes
CDN migrations, redirects, authentication changes, WAF rules, IPv6 rollout, and domain changes can alter check behavior even if Pingdom itself has not changed.
When This Setup Makes Sense
A Pingdom HTTP(S) uptime check is appropriate when your primary question is:
"Is this endpoint externally reachable and responding as expected?"
Use a transaction check when you instead need to know:
- can a user submit a form;
- can a customer log in;
- does a search return expected content;
- can a checkout flow progress through multiple pages; or
- does a JavaScript-driven workflow complete successfully?
The next tutorial covers that deeper synthetic workflow.
FAQ
What is the difference between a Pingdom check interval and alert timing?
The interval controls how often the check runs. Alert settings determine when a failure results in a notification. They are related but not identical.
Why does Pingdom fail while my website loads normally?
The synthetic request can differ from your browser by location, cookies, authentication, redirects, DNS path, or security treatment. Inspect the exact failure rather than assuming either Pingdom or the browser is wrong.
Should I monitor the homepage or a health endpoint?
Monitor the endpoint that represents the failure you need to detect. A homepage includes more of the public delivery chain; a health endpoint can provide a cleaner application-specific signal. Many production systems eventually monitor both for different purposes.
Does a green Pingdom uptime check prove JavaScript works?
No. The basic HTTP check is not a full user browser journey. Use transaction monitoring when browser interaction and multi-step functionality are part of the success condition.
Conclusion
A useful Pingdom uptime check is simple, explicit, and testable. Choose the endpoint carefully, select a representative interval and region, configure only the request options you actually need, attach the right alert recipients, and run Test Check before creating it.
Then verify live history rather than assuming setup success from the configuration form. If a check fails, compare Pingdom's request with the service's DNS, TLS, HTTP, security, and server evidence.
For a deeper check that proves a multi-step user flow, continue with How to Set Up Transaction Monitoring in Pingdom.
References
- SolarWinds Pingdom Documentation — "How to set up an uptime (HTTP) check" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/topics/how-to-set-up-a-http-s-check.htm — accessed September 10, 2026.
- SolarWinds Pingdom Documentation — "Create your first check" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/gsg/create-check.htm — accessed September 10, 2026.
- SolarWinds Pingdom Documentation — "Pingdom Getting Started Guide" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/pingdom_getting_started_guide.htm — accessed September 10, 2026.
- SolarWinds Pingdom Documentation — "What is a check?" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/topics/what-is-a-check-.htm — accessed September 10, 2026.