Website monitoring sends automated HTTP requests to your URLs on a schedule, validates the response, and alerts you when something fails. That's the entire concept. The details—where checks run from, what they validate, how failures get confirmed—are what separate a useful setup from one that pages you at 3am for a blip.
This article walks through the mechanics: what happens when a check runs, what gets measured, and how alerts actually fire.
TL;DR
A monitoring service hits your URL from external servers on a fixed interval (usually every 1–5 minutes). Each check verifies the HTTP status code, response time, and optionally content in the body. Failed checks are confirmed before alerting to reduce false positives. Alerts go to email, Slack, Discord, or webhooks. Multi-location checks catch regional outages. Website monitoring tells you if the site works for users—not what's happening inside your server.
Why this matters
Your website can fail in ways your server dashboard won't show. The process might be running, CPU might be fine, and your `/health` endpoint might return 200—while the homepage serves a blank page, checkout returns 500 errors, or users in Europe can't resolve your DNS.
Website monitoring answers one question from the outside: can someone actually use this URL right now? That's the same question your customers ask. Internal tools answer different questions—process health, memory usage, log errors. Both matter, but external website monitoring is what catches user-visible failures first.
If you only monitor from inside your network, you're testing a path your users never take. Your office IP might bypass the CDN. Your VPN might hit an internal load balancer. External monitoring removes those blind spots.
How it works
Every website monitor follows the same pipeline: schedule, probe, validate, confirm, alert, record.
1. Scheduling
You configure a URL, check interval, and validation rules. The monitoring service queues that check to run every N minutes—1 minute for production apps, 5 minutes for lower-priority sites. On Uptinio, 1-minute intervals require a paid plan; the free plan starts at 5 minutes.
2. Probing
When the schedule fires, the service sends an HTTP request from one or more probe locations. These are servers in datacenters around the world—not your infrastructure. Common locations include US East, US West, EU West, and Asia Pacific.
The probe performs a real HTTP request, the same kind a browser or API client would make:
# Simplified version of what a probe does
curl -s -o /tmp/response.html -w "\nHTTP Code: %{http_code}\nTime: %{time_total}s\n" \
-H "User-Agent: UptimeMonitor/1.0" \
--max-time 30 \
https://example.com/Most monitors support GET requests by default. Some allow POST with custom headers and body—for API endpoints that require authentication or specific payloads.
3. Validation
The probe doesn't just check "did we get a response." It validates specific conditions you configure:
| Basic check | Advanced check | |
|---|---|---|
| Validates | Status code only | Status code, content, and timing |
| Example | 200 OK | 200 OK with expected body under 2s |
| Catches | Server completely down | Server up but serving an error page |
| Misses | Broken app behind a healthy load balancer | Little that is user-visible if configured well |
A monitor that only checks status codes will miss the case where your app returns 200 with an error page body. Always validate content on critical endpoints.
4. Confirmation
A single failed check doesn't trigger an alert immediately. The service waits for confirmation—typically 2–3 consecutive failures, or failures from multiple locations within a short window.
This filters out transient issues: a packet dropped between the probe and your server, a brief GC pause, a momentary network hiccup. Without confirmation, you'd get alert fatigue from noise that never affected a real user.
The tradeoff: confirmation adds delay. A 1-minute check interval with 2-failure confirmation means you might not alert until 2–3 minutes after the outage starts. For most production services, that's acceptable. For payment systems, some teams use the shortest interval their plan allows with single-failure alerting during business hours.
5. Alerting
Once a failure is confirmed, the monitoring service sends notifications through your configured channels:
Good platforms also create an incident record—start time, affected monitor, duration, resolution time. That history feeds uptime reports and postmortems.
6. Recording
Every check result gets stored: timestamp, location, status code, response time, pass/fail. Over time this builds uptime percentage, latency trends, and outage history. Monthly uptime reports come from this data.
Multi-location probing
Checks run from independent datacenters worldwide—not your infrastructure—so you see what users see.
Content validation
Match keywords, JSON fields, or headers in the response to catch "200 OK but broken" scenarios.
SSL monitoring
Verify certificate expiry and chain validity on every HTTPS check, with dedicated expiry alerts.
Response time tracking
Measure latency on every check and alert when performance degrades before complete failure.
Step-by-step guide
Here's how to set up website monitoring that actually catches real problems.
1. Pick the URLs that matter
Don't just monitor your homepage. List the URLs on the critical user path:
2. Create an HTTP monitor for each URL
For each URL, configure:
3. Enable multi-location checks
Select at least two probe locations in different regions. If you have global users, pick locations close to your user base. If your app is US-only, US East + US West is enough.
4. Set confirmation rules
Start with 2 consecutive failures before alerting. Tune down to 1 if you have a high-traffic payment endpoint and can tolerate occasional false positives. Tune up to 3 if you're getting noise from a flaky network path.
5. Configure alert channels
Route critical monitors (login, API, payment) to Slack with @channel or PagerDuty. Route informational monitors (marketing site, docs) to email only.
6. Add SSL monitoring
For every HTTPS URL, enable SSL certificate monitoring. Set alerts at 30, 14, and 7 days before expiry. This is separate from the HTTP check—dedicated SSL monitors track certificate lifetime even when the site is up.
7. Test it
Break something on purpose. Stop your web server, return a 500 from your health endpoint, or remove the keyword your monitor expects. Verify the alert arrives within the expected window. If it doesn't, your configuration has a gap.
// Example health endpoint your monitor should hit
app.get("/health", async (req, res) => {
const dbOk = await checkDatabaseConnection();
if (!dbOk) {
return res.status(503).json({ status: "error", message: "Database unreachable" });
}
res.status(200).json({ status: "ok", timestamp: Date.now() });
});Configure your monitor to expect status 200 and keyword "status":"ok". A monitor hitting this endpoint catches database failures that a simple process-health check would miss.
Best practices
Best Practice: Monitor the readiness endpoint, not just liveness. `/health` that returns 200 when the process is alive isn't enough. `/ready` that verifies database and cache connectivity catches real failures.
Best Practice: Validate response content on critical endpoints. Status code 200 with an error page is still a failure. Match a keyword or JSON field that confirms correct behavior.
Best Practice: Set response time thresholds based on real user expectations. Three seconds is too slow for a login page. Ten seconds might be fine for a report generation endpoint.
Best Practice: Monitor from at least two locations. Single-location monitoring misses regional DNS failures, CDN misconfigurations, and geo-routing issues.
Best Practice: Separate monitors per critical path. One monitor on the homepage doesn't tell you checkout is broken. Each step in the user journey deserves its own check.
Best Practice: Review response time trends weekly. Latency often degrades before complete failure. A monitor that alerts on slow responses gives you time to fix things before users notice.
Common mistakes
Example failure scenarios
The 200 OK error page
An e-commerce site configured a basic HTTP monitor on their checkout URL. Status code: 200. During a deploy, a misconfigured nginx rule served a static "We'll be back soon" page with HTTP 200. The monitor stayed green for 45 minutes while no one could complete a purchase. Adding a keyword check for checkout-form would have caught it on the first failed check.
Regional DNS failure
A SaaS company migrated DNS providers on a Friday afternoon. US probes passed immediately. EU probes failed for 90 minutes due to stale DNS records at a European resolver. The team in San Francisco saw all green dashboards. European customers couldn't reach the app. Multi-location monitoring from London would have flagged it within minutes.
Slow degradation before outage
An API monitor tracked response times alongside status codes. Over three days, average latency climbed from 200ms to 2800ms—still returning 200 OK. The team got a "slow response" alert before the database connection pool exhausted and the API started returning 503 errors. They scaled the database before users noticed.
Redirect loop after deploy
A marketing site monitor followed redirects (www → non-www → www). After a deploy changed redirect rules, the site entered an infinite redirect loop. External monitoring detected it immediately. Internal checks that hit the server directly bypassed the CDN and never saw the loop.
Frequently Asked Questions
How does website monitoring work?
Automated HTTP requests from external servers on a schedule. Each request validates status code, response time, and optionally content. Confirmed failures trigger alerts.
Is website monitoring the same as ping monitoring?
No. Ping (ICMP) monitoring checks if a host is reachable at the network level. HTTP monitoring checks if your web server responds correctly to an application-level request. A server can respond to ping while the website is broken, and vice versa. For websites, HTTP monitoring is what you want.
How often should checks run?
Every 1 minute for production customer-facing sites. Every 5 minutes for marketing sites and internal tools. Faster intervals catch outages sooner but cost more and generate more data. On Uptinio, 1-minute checks are available on paid plans and the free plan has a 5-minute minimum.
What's a good response time threshold?
Depends on the endpoint. Login and homepage: 2–3 seconds. API endpoints: 500ms–1 second. Background report generation: 10–30 seconds. Set thresholds based on what your users tolerate, not arbitrary numbers.
Can website monitoring check authenticated pages?
Yes. Most platforms support custom headers (Authorization bearer tokens, cookies) or POST requests with credentials. Be careful storing secrets in monitoring configs—use short-lived tokens or dedicated monitoring accounts with minimal permissions.
Does website monitoring work with SPAs and JavaScript-heavy apps?
Basic HTTP monitoring checks the initial HTML response. It won't execute JavaScript or interact with the page. For JS-heavy apps, use synthetic monitoring backed by a browser monitor that runs a real browser, or monitor a backend API endpoint that confirms the app is functional.
What happens during planned maintenance?
Pause your monitors before maintenance starts. Most platforms let you pause individual monitors or entire groups. Unpause when maintenance is complete. Some teams integrate maintenance windows with their status page so customers know what's happening.
Final Thoughts
Website monitoring is not complicated. An HTTP request, a validation rule, a confirmation window, an alert. The hard part is configuring it well—checking the right URLs, validating the right content, alerting the right people, and not crying wolf on every blip.
Start with your most critical URL. Add content validation. Enable two probe locations. Test that alerts work. Then expand to the rest of your user journey.
The mechanics are simple. The discipline of maintaining and tuning your monitors over time is what separates teams that catch outages in minutes from teams that find out on Twitter.
Related Articles
Related monitors
Set up your first website monitor in minutes—start with your most critical URL and expand from there.