A server can be healthy while a public website is unavailable because of DNS, TLS, CDN, routing, reverse-proxy, or application failures. Site24x7's Website monitor checks an HTTP(S) URL from external monitoring locations and can apply availability rules and notification profiles.
This tutorial uses the current Website monitor documentation—not the separately indexed old-client help pages—to create a minimal reliable external check, select representative locations, attach notification behavior, verify the configuration before saving, and troubleshoot false or real downtime.
Last verified: September 10, 2026. Site24x7's current Website monitor page contains plan-dependent frequencies and many advanced options. Recheck current availability in your account instead of treating every option below as permanent.
What You'll Accomplish
You will:
- create a Website monitor from the current Web interface;
- choose an appropriate URL and check frequency;
- select primary/secondary monitoring locations;
- configure availability/timeout behavior carefully;
- attach a notification profile and user/on-call destination;
- use Check and Save to validate the configuration; and
- diagnose DNS, TLS, regional, timeout, and security-filter failures.
Prerequisites
You need:
- a Site24x7 account;
- permission to create Website monitors/configuration profiles;
- a public HTTP(S) URL;
- at least one monitoring location;
- a user group/on-call schedule or other notification target; and
- a non-production/test path if you want to validate failure notifications safely.
Quick Answer
Go to Web → Website (+), give the monitor a display name, enter the public URL, choose the check frequency and at least one primary monitoring location, then configure only the advanced settings you need. Attach a Notification Profile and the correct user group/on-call schedule. Use Check and Save so Site24x7 validates the configuration before saving. After creation, review recent checks from the chosen locations. If one region reports downtime, investigate DNS/TLS/network path and the exact failure before changing thresholds. Use multi-location downtime rules when appropriate to reduce false alerts without hiding real regional outages.
Step 1: Open the Current Website Monitor
Current Site24x7 documentation gives the path:
Web → Website (+)
Enter:
- a descriptive Display Name;
- the Webpage URL.
Example name:
Customer portal - public HTTPS
Avoid generic names such as Website monitor 1.
Do not use an old /help-oldclient/ screenshot or menu path as the authoritative workflow.
Step 2: Choose the URL Based on User Impact
A good external check represents something the user depends on.
Possible choices:
- public homepage;
- login page;
- API readiness endpoint;
- regional service endpoint.
The homepage exercises more of the public delivery chain. A health URL can provide a cleaner application signal.
Many mature systems monitor both, but they should remain separate checks if they represent different failure modes or owners.
Step 3: Choose the Check Frequency Deliberately
Current Site24x7 documentation says Website monitoring frequencies can range from 10 seconds to one day, but the shortest intervals are restricted to particular plans/configurations and can consume additional monitor licenses. It also states that one minute is the minimum for users outside the listed short-interval entitlements.
These are product details that can change.
Do not choose 10 seconds simply because it is the fastest visible option. Consider:
- required detection time;
- endpoint cost;
- expected incident-response time;
- false-positive risk;
- license/plan impact.
A faster poll does not fix a noisy success condition.
Step 4: Select Monitoring Locations
Site24x7 currently documents more than 130 global locations for Website monitoring and requires at least one primary location in the setup.
Choose locations based on actual users and network architecture.
For example:
- Europe-heavy users → at least a relevant European location;
- globally distributed service → representative locations across major user regions;
- private/internal service → consider the supported On-Premise Poller approach rather than exposing it publicly.
Do not interpret one-region failure automatically
If one location fails while others pass, possible causes include:
- regional DNS behavior;
- CDN edge failure;
- ISP/network path;
- geofencing;
- WAF policy; or
- a localized Site24x7 path issue.
Investigate before classifying it as noise.
Step 5: Configure Timeout and Availability Rules
The current Website monitor page includes a Connection Timeout option. Site24x7 describes it as the maximum time allowed to establish the connection before reporting a failure such as "Could not establish connection."
Choose a value aligned with what users should tolerate.
Do not increase the timeout repeatedly to make a slow service appear healthy. If external connections regularly exceed the user-performance objective, the monitor may be exposing a real problem.
Multi-location downtime rules
Site24x7's current Threshold and Availability profile can define how many monitoring locations must report a problem before the monitor is considered down. The documentation allows up to eight locations in these downtime rules.
This can reduce false alerts caused by one transient path, but it changes what "down" means.
If a service must be available in every customer region, requiring many locations to fail can hide a serious regional outage.
Use multi-location confirmation when it matches the availability objective—not as a generic anti-noise switch.
Step 6: Add Content/HTTP Checks Only When They Improve the Signal
The Website monitor supports richer options, including content/keyword behavior and HTTP configuration.
Use them only when they detect a meaningful failure.
For example, checking for a stable SERVICE_OK marker may catch a 200 response that contains an application error page.
Do not check a marketing sentence that editors can change without an outage.
Similarly, store HTTP headers/response content only when you need the diagnostic data and accept the privacy/licensing implications. Current docs state stored data can flow to AppLogs and consume related licensing.
Step 7: Create or Select a Notification Profile
Site24x7's current Notification Profile controls status-based notification behavior such as:
- delay before Down/Trouble/Critical alerts;
- persistent/repeated alerts;
- notification methods;
- escalation timing; and
- related notification behavior.
Create a profile through:
Admin → Configuration Profiles → Notification Profile
Then attach the appropriate profile to the Website monitor.
Use consecutive-failure delay deliberately
Site24x7 gives an example where a profile alerts only after three consecutive failures to reduce noise from brief network glitches.
That is an example—not a universal recommendation.
If your service objective requires immediate response, three missed checks may be too slow. If one short probe failure is common and non-actionable, confirmation can be appropriate.
Step 8: Attach the Correct Responders
The current Website monitor page includes:
- User Alert Group;
- On-Call Schedule;
- Notification Profile;
- third-party integrations.
Separate these concerns:
- monitor = what failed;
- threshold/availability profile = when state changes;
- notification profile = how/when messages repeat/escalate;
- user/on-call group = who owns the response.
Do not send a new, unvalidated monitor to the entire organization.
Step 9: Use Check and Save
The current Website monitor page provides Check and Save.
Site24x7 states that it runs the configuration and saves the monitor when it performs correctly; if there is an error, the monitor is not saved.
Use this validation path rather than simply clicking Save and waiting for an alert.
It can expose problems such as:
- wrong URL;
- connection failure;
- DNS issue;
- TLS problem;
- response-content mismatch; or
- authentication/configuration error.
Step 10: Verify Live Monitoring After Creation
After the monitor is created, review:
- latest status;
- monitoring-location results;
- response time;
- recent history;
- threshold/availability state;
- notification-profile assignment.
Do not assume Check and Save proves long-term health. It validates the configuration at one point; scheduled checks establish ongoing evidence.
Verify the Setup
A Site24x7 Website monitor is ready when:
- it targets the intended public URL;
- frequency matches your detection objective and account capability;
- the primary location is representative;
- additional locations have a reason;
- timeout/downtime rules are intentional;
- the correct Notification Profile is attached;
- the intended responders/on-call schedule are attached;
- Check and Save succeeds; and
- multiple scheduled checks show the expected healthy state.
Safely test alerts
Use a temporary monitor or controlled test endpoint rather than taking production offline.
Attach only test-safe recipients, cause the test endpoint to fail in a known way, and observe the resulting monitor state/notification.
Restore/delete the test resource afterward.
This is a validation method, not a claim that PerfMonitoring executed a live Site24x7 incident.
Common Problems and Fixes
Problem: One location says Down while others say Up
Cause: regional network/CDN/DNS/WAF behavior.
Fix: compare results by location, inspect CDN/WAF/server logs and DNS answers, and determine whether the regional failure affects real users before changing availability rules.
Problem: "Could not establish connection"
Cause: connection timeout, network path, firewall, or target service not accepting the connection.
Fix: verify DNS, TLS/TCP reachability, firewall/WAF behavior, and whether the configured connection timeout reflects an acceptable user experience.
Problem: The URL works manually but Check and Save fails
Cause: your browser has cookies/authentication, follows different content flows, or comes from an allowed network.
Fix: compare the synthetic request with the browser request. Remove dependencies on personal sessions and use explicit supported authentication when required.
Problem: Too many alerts from short glitches
Cause: notification/downtime rules are more sensitive than your operational objective.
Fix: first confirm the endpoint is not genuinely unstable. Then use consecutive-failure or multi-location rules only if they match your availability policy.
Problem: No one receives an alert
Cause: missing user group/on-call schedule, wrong Notification Profile, or integration/channel configuration.
Fix: inspect all four layers: monitor status, threshold state, notification profile, and responder assignment.
Problem: Site24x7 traffic affects analytics
Cause: external synthetic monitoring generates requests.
Fix: identify Site24x7 synthetic traffic using current vendor guidance if you need to separate it from real-user analytics. Do not filter it out of server logs used for incident diagnosis.
Best Practices
Keep external uptime separate from server health
A healthy server does not guarantee the public site is reachable. Use both when they answer distinct operational questions.
Choose locations from user geography
More locations are not automatically better. Pick locations that represent customers or critical network paths.
Use stable content assertions
If you add a keyword check, use a durable machine-oriented marker rather than content that editors routinely change.
Make notification ownership explicit
Every monitor should map to a team/on-call response path and a runbook.
Review thresholds after real incidents
Use evidence from false positives and real outages to adjust confirmation, location rules, and notification behavior.
When This Setup Makes Sense
Site24x7 Website monitoring is appropriate for external HTTP(S) availability and response behavior.
Use Linux Server Monitoring for host CPU/memory/process telemetry. Use Web Transaction/Browser monitoring when the success condition requires multi-step browser interaction rather than a single request.
FAQ
Which Site24x7 locations should I choose?
Choose locations that represent important users or network paths. Start with a primary region and add others when regional evidence changes your incident decision.
Why is a website down from one location only?
Regional DNS, CDN, ISP, firewall/WAF, routing, or origin behavior can differ. Treat a single-region failure as diagnostic evidence rather than automatically ignoring it.
How do Notification Profiles affect Website alerts?
They control when and how Site24x7 sends status notifications, including delays, persistent notifications, media, and escalation behavior. They are separate from the Website monitor's success condition.
Should I use the fastest polling interval?
Only if your detection requirement justifies it and your account supports it. Faster polling can increase license usage and does not correct a poorly defined monitor.
Conclusion
A reliable Site24x7 Website monitor starts with a user-relevant URL, representative locations, and a clear availability rule. Attach deliberate notification behavior, validate with Check and Save, then inspect ongoing check history.
Do not hide regional or performance failures by blindly increasing timeout or failure-confirmation settings. Tune from evidence and the service objective.
For host-level telemetry, use How to Set Up Linux Server Monitoring with Site24x7.
References
- Site24x7 Online Help — "Add an Uptime Check for a Website" — https://www.site24x7.com/help/admin/adding-a-monitor/website-monitoring.html — accessed September 10, 2026.
- Site24x7 Online Help — "Notification Profile" — https://www.site24x7.com/help/admin/configuration-profiles/notification-profile.html — accessed September 10, 2026.
- Site24x7 Online Help — "Threshold and Availability for Website" — https://www.site24x7.com/help/admin/configuration-profiles/threshold-and-availability/website.html — accessed September 10, 2026.
- Site24x7 Online Help — "Threshold and Availability" — https://www.site24x7.com/help/admin/configuration-profiles/threshold-and-availability/ — accessed September 10, 2026.