The monitor timed out, but the administrator could open the page. This combination suggests at least three possibilities: the check location’s route briefly failed, the site was unavailable to some visitors, or the success condition is outdated. Classifying the event requires data from two requests made during the same period.
Classify the event before adjusting thresholds
First, write down exactly what the monitor considered an error: a DNS timeout, connection failure, TLS failure, HTTP status, missing text, or response time exceeding the limit. Add the URL, time, check location, number of attempts, and raw response. Saying “the site went down” obscures the key distinction between layers.
Use this table as a starting point:
| Observation | Preliminary classification | Next check |
|---|---|---|
| One location failed, while two others succeeded immediately | A route or the location itself may have failed | IP, route trace, location history |
| IPv4 works, but IPv6 consistently fails | Possible genuine partial outage | AAAA record and IPv6 route |
| The browser sees the page, but the monitor receives 403 | Different access rules | WAF response and log |
| The status and page are correct, but the searched text has changed | Outdated condition | Choose a stable marker |
| Several locations receive the same 5xx | Server-side incident | Proxy, application, dependencies |
An event can be called false if the user-facing property being checked remained functional throughout, and the error occurred in the measurement itself or its incorrect condition. A regional outage, broken IPv6, and blocking a real group of clients are still partial outages.
The components of a reliable check and retry strategy are described in the uptime monitoring guide.
DNS can send clients to different addresses
An employee and the monitor use different resolvers. Because of TTL, geographic DNS, a staged migration, or caching, they may receive different A and AAAA records. Compare the result saved during the alert with the expected pool of addresses. A check several hours later will not recover the resolver’s earlier response.
A published AAAA record requires a separate IPv6 test. One client prefers IPv6, while another quickly falls back to IPv4. The site will open for its owner, but visitors with a working IPv6 route may reach a broken node. It is risky to dismiss this alert as noise.
A CDN will naturally direct different regions to different edge servers. An error on one node has a limited scope, but affects real users on that route. To confirm, compare several locations, the IP addresses they receive, and headers that identify the edge.
Record four values in the event: the resolver, A record, AAAA record, and the address the client actually connected to. They often explain the discrepancy before you need to inspect the application.
Network and TLS conditions vary between clients
The overall text timeout may refer to DNS delay, TCP connection time, TLS handshake time, time to first byte, or the entire response. If the monitor shows individual stages, compare each one with its usual history. If it only shows the total, repeat the diagnostic request with a tool that separates the timings.
A timeout that is too short reacts to a normal cold cache and occasional network delays. One that is too long increases the time it takes to detect degradation. Choose the threshold based on the distribution of normal values and the delay users can tolerate. The fastest possible startup is not suitable for this purpose.
Clients differ in their trusted certificate authorities, protocol versions, SNI, and ability to complete an intermediate certificate chain. A browser may sometimes use a cached certificate, while a clean agent shows that the server’s chain is incomplete. This points to compatibility issues for some clients. Compare the certificate presented, the hostname, and the specific node; practical commands are available in the article on SSL certificate errors.
Disabling certificate verification is acceptable as a short diagnostic experiment. In a permanent check, it hides user-facing TLS errors.
The WAF sees the monitor as a different visitor
A data center IP, request frequency, lack of a cookie, and User-Agent may trigger security rules. The monitor may receive 403, 429, or a browser verification page, while an employee using a home address gets a normal response. Open the WAF log for the exact time and match the event ID, rule, and action.
If the monitoring system needs technical access, use a limited and verifiable method: a known IP, a signed request, or a separate secure endpoint. Allowing any request with a particular User-Agent is easy to spoof and creates a security hole.
Add up the frequency of requests from all monitoring systems. Several independent agents can exceed the shared rate limit. However, fully excluding the external route from the WAF would prevent the check from detecting the same restrictions users encounter. Usually, two signals are needed: an internal health check for the component and an external request through public-facing protection.
HTTP success depends on the expected behavior
Browsers follow redirects automatically. The monitor may stop at the first 301 or reach a login page with code 200. Save each step, the final domain, and the status. A reference for response values is available in the HTTP status codes guide.
Define success for the specific URL. Examples:
- the old HTTP address should redirect to the primary HTTPS domain in one step;
- a public product page should return 200 and the test product code;
- a private account page should redirect to the agreed login page;
- a health API should return 200 and a field with the expected state.
A check string can break after an editorial change, localization, or A/B test. Choose an element that changes with the functionality: a technical attribute, the name of a stable test object, or a section heading. A dynamic price and advertising slogan will generate unnecessary alerts.
A simple HTTP agent reads the raw response and does not execute JavaScript. If an element only appears in a browser, you will need a synthetic browser test or a server-side indicator. A full HTML checksum is rarely suitable for a dynamic page.
Configure confirmation based on the type of failure
A retry should answer a specific question. A second request from the same location after 20 seconds filters out brief packet loss. A request from another region assesses the scope. Separate IPv4 and IPv6 checks reveal protocol differences. Checking for text distinguishes a working page from a placeholder.
Do not apply one strategy to every error. For a complete lack of TCP connectivity, two quick confirmations may be enough. Borderline response times are more useful to assess over a window and by the percentage of slow requests. A change to editorial text should first be checked against the publication log.
After investigating, change only the relevant part of the condition: the timeout, number of attempts, marker, or expected redirect. Test the new rule against a normal response and a controlled error. Simply increasing all thresholds will reduce the number of alerts while also reducing sensitivity.
Account for the specific monitor’s route
reChecker Uptime Monitor retries a request using forced IPv4 after a network failure. Therefore, broken IPv6 may not trigger an alert; the service also does not show separate DNS, TCP, and TLS timings. Record this limitation alongside the event and check IPv6 and certificate trust using independent tools.
In the event record, separate four things: the saved signal, the user impact, the identified cause, and the configuration change. If the error disappears before retries, leave the status as “cause undetermined” and retain the data for comparison. After a month, group events by these statuses: a recurring route issue or an increasingly outdated marker will become visible without raising all thresholds.