A downtime alert tells you where to look. Finding the cause means connecting the failed check to the service, server and recent changes behind it.
Confirm what is failing.
Start with the monitor’s target and check history. Is the entire website unavailable, or is a single API endpoint returning an error? Compare checks from different regions to see whether the problem is widespread.
A failed keyword or JSON check can reveal an application problem even when the server returns HTTP 200. Read the condition that failed before treating it as a network outage.
Use the response as a clue.
A connection timeout, DNS failure and HTTP 502 point to different parts of the request path. Review the response and the time of the first failure, then check the components that handle that request.
The order of events matters. A resource spike just before the failed check can be more useful than a high metric observed afterwards.
Look behind the endpoint.
If the service runs on a monitored server, compare CPU, memory, disk and network usage around the start of the incident. Look at the processes using those resources.
- Is the disk full, preventing the application from writing files?
- Did memory pressure coincide with a process stopping?
- Did CPU usage rise before response times increased?
- Was there a deployment or configuration change at the same time?
Statance’s AI investigation can bring checks and server metrics together to suggest a likely cause. Treat that explanation as a starting point and verify it against the underlying data.
Check that recovery holds.
After taking action, confirm successful checks from the affected regions. Review response times and server metrics to see whether the underlying condition has improved.
A recovery notification closes the immediate loop. A follow-up resource alert can help you catch the same condition earlier next time.