Start with the exact URL that matters
Check the exact page that a visitor uses, not only the homepage. A homepage can be available while a sign-in route, checkout, dashboard, or contact form is failing. Copy the complete URL and note the time you first saw the problem.
Open the page in a private browser window or another browser. This helps rule out a stale session, browser extension, or cached page. If the page requires a login, make sure the monitor is configured for a response it can actually receive.
- Record the page URL and the visible error message.
- Note whether the problem affects one page or several important pages.
- Check whether visitors can still reach the homepage and other key routes.
Read the response instead of guessing
An HTTP status code is useful evidence. A 500-range response means the request reached a server or intermediary, but that server could not complete the request as expected. A timeout means the check did not receive a completed response within its configured limit. DNS, TLS, and connection failures point to different parts of the delivery path.
The code alone does not prove the root cause. Use it to choose the next place to look: application logs for 500 errors, proxy and upstream health for 502 or 504, provider status for 503, DNS records for resolution failures, and certificate details for TLS failures.
Use repeated checks as outage evidence
One failed request can be temporary. Repeated observations make it easier to distinguish a short network blip from an incident worth investigating. AliveRadar records the HTTP status, error category, response time, and timestamp for each page so you can see whether the same pattern continues.
When a failure is confirmed, compare the last successful check with the failed checks. This gives your team a useful time window for logs, deployments, database metrics, and provider events.
A short outage-check checklist
Keep the response calm and specific. Confirm the affected route first, then work from the observed error toward the service that may be involved.
- Confirm the exact failing URL and the latest recorded response.
- Review the monitor’s recent checks and incident timeline.
- Check recent deployments, provider status, and application or proxy logs.
- Publish a status update if visitors need to know about the interruption.
- Confirm recovery with a successful check before closing the incident.