I get asked fairly regularly what WebMon actually does when it checks a website. The answer is straightforward, but there are a few nuances worth understanding - especially if you're trying to figure out why a check failed or what a particular status means.
What Happens During a Check
Every check interval (anywhere from 1 minute to 24 hours depending on your plan and settings), our monitoring system sends an HTTP request to your URL. It's essentially the same as if someone typed your URL into a browser, except we're only interested in the server's response - not rendering the page.
Here's the sequence:
- We send a GET request to your URL
- If your site uses HTTPS (it should), we verify the SSL certificate is valid
- We follow redirects if you've enabled that option
- We record the HTTP status code, response time, and response headers
- For keyword monitors, we also scan the response body for your specified text
The whole process takes a fraction of a second for a healthy site. We record the response time in milliseconds so you can track performance over time.
What the Status Codes Mean
Your monitor shows a status based on what we get back:
Up (green) - We got a 2xx response (usually 200 OK). Your site is reachable and responding normally. For keyword monitors, this also means the keyword check passed.
Down (red) - Either we couldn't connect at all (timeout, DNS failure, connection refused) or the server returned a 5xx error (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable). Something is wrong.
Degraded (amber) - The site responded but something isn't ideal. This could be a slow response time exceeding your threshold, a 4xx error, or an SSL certificate approaching expiry.
We don't alert on the first failure. By default, a monitor needs two consecutive failed checks before we mark it as down and send an alert. This avoids false alarms from momentary blips - a single timeout doesn't necessarily mean your site is down.
The Difference Between a Timeout and a Failure
These get confused a lot:
A timeout means we sent the request and didn't get a response within the time limit. The server might be overloaded, the network path might have a problem, or the server might have crashed entirely. We don't know - we just know we didn't hear back.
A failure (5xx error) means the server responded, but told us something went wrong on its end. A 500 error means the application crashed. A 502 means the reverse proxy (Nginx, Cloudflare) couldn't reach the application server. A 503 means the server is temporarily unavailable, often due to maintenance or overload.
Both count as "down" for alerting purposes, but the distinction matters for debugging. A timeout suggests network or resource issues. A 5xx error points to application or configuration problems.
Redirect Following
By default, monitors follow redirects. If your site redirects from http:// to https://, or from www to non-www, we follow the chain and report the final destination's status. This is usually what you want.
If you toggle redirect following off, we report the status of the initial response. A 301 redirect would show as a redirect rather than the final page. This is useful if you specifically want to verify that a redirect is in place.
WebMon also tracks your redirect chain. If the chain changes - say a new redirect gets inserted or an existing one points somewhere different - you can set up alerts for that too.
Reading Your Check History
The checks table on your monitor's detail page shows every individual check. A few things to look for:
Response time column - This is your friend for spotting performance issues. Sort by response time to find the slowest checks. If your average is 300ms but you occasionally see 4000ms, something is causing intermittent slowdowns.
Status patterns - A single red check surrounded by green is usually a blip. Multiple red checks in a row are a real outage. Alternating red and green (flapping) suggests an unstable server that's struggling to stay up.
Time of day - Do your failures cluster at specific times? Early morning failures might coincide with backup jobs. Business-hours slowdowns might indicate traffic exceeding your hosting plan's capacity.
When WAF Gets in the Way
Some websites are behind a Web Application Firewall (Cloudflare, Sucuri, etc.) that blocks automated requests. If your monitor keeps failing with a 403 Forbidden or shows a Cloudflare challenge page, it's the WAF blocking our checker, not your site being down.
WebMon detects this automatically and can switch to browser-based checking, which renders the page like a real browser and passes WAF challenges. If your monitor has been flagged for browser mode, you'll see an indicator on the monitor detail page.
The Short Version
We hit your URL, record what happens, and tell you if something changes. The details matter when you're debugging an issue, but the core value is simple: you'll know your site is down before your customers do.
View your check history and response time graphs on any monitor's detail page. Click through from your dashboard.