Troubleshoot a failed check
Start with evidence, not assumptions
A failed check means one observation did not match the monitor’s healthy rules. It is a reason to inspect the details—not automatic proof that the entire service is offline.
Move from symptom to evidence to action
Start with the exact failed check before changing thresholds or disabling alerts.
A monitor shows failed
Do not change settings yet.
Open the check log
Compare time, region, and reason.
Fix the actual cause
Target, assertion, route, or service.
Before changing anything, record the failed check’s time, region, and reason. Changing several settings at once can hide the original cause and make the next failure harder to understand.
Quick checks anyone can do
Open the same address
Try the monitored address in a private browser window. A private window avoids relying on an existing signed-in session.
Confirm the address
Check https://, spelling, subdomain, and path. A working homepage does not prove that a misspelled health-page path works.
Look at other regions
If one region failed and the others passed, the issue may be local. If several regions failed together, broader service impact is more likely.
Read the exact reason
Open the check-log row. The failure category points to the next useful step.
Check for planned work
Confirm whether a deployment or maintenance window overlapped the failure.
“Connection failed”
Uptime could not establish a connection to the target.
Check whether:
- the hostname is correct;
- the service is reachable from the public internet;
- a firewall or allowlist blocks monitoring regions;
- the TCP port is correct;
- the service accepts the selected protocol.
If your service is private, public probes cannot reach it without a supported private connectivity design. Do not expose a private administration endpoint simply to make a monitor pass.
“Request timed out”
The service did not finish responding before the configured timeout.
Open the page yourself and compare its normal response time with the timeout. Then compare average and p95 history on the monitor chart.
- If normal p95 is close to the timeout, the monitor may be stricter than the normal customer experience.
- If several regions became slow at once, investigate the service or a shared provider.
- If only one region slowed, inspect the regional network path.
Raise the timeout only when the longer wait still represents an acceptable customer experience.
“Unexpected status”
The website replied, but its status was outside the accepted range.
Common examples:
401or403: the page requires authentication or blocks the probe;404: the path does not exist;429: the service is rate limiting requests;500–599: the application or upstream service reported an error.
If the page intentionally redirects, enable Follow redirects or accept the intended redirect behavior. Do not accept every status simply to turn the monitor green; that can make real application errors look healthy.
“Keyword missing”
The page loaded but did not contain the expected text.
Check whether the text:
- was edited by a content or marketing change;
- appears only after JavaScript runs in a browser;
- changes by language, location, or signed-in state;
- is case-sensitive;
- is returned in the actual server response.
Choose a stable marker. If page text is not truly part of service health, switch to a normal HTTP monitor.
SSL or certificate failure
SSL allows a browser to trust an https:// connection. Certificate failures may involve expiration, a hostname mismatch, an incomplete certificate chain, or a handshake problem.
Confirm the exact hostname and certificate details. A certificate for example.com may not automatically cover every subdomain. Ask the person who manages the website or hosting provider to renew or correct the certificate.
Do not disable SSL checking permanently to silence a genuine customer-facing trust problem.
DNS failure
DNS failures mean the name could not be resolved as expected.
Check:
- whether the domain is registered and active;
- whether the record exists;
- whether the expected record value is current;
- whether a recent DNS change is still propagating;
- whether results differ by region.
During an intentional DNS change, publish a maintenance window and monitor both the old and new behavior where practical.
Ping fails but the website works
This is common. Many websites block ICMP ping intentionally.
Create an HTTP monitor for the website instead. Use ICMP only when the target is expected to answer pings and that response is the capability you need to verify.
When to change thresholds
Thresholds filter brief evidence; they do not fix an inaccurate check.
Change a threshold after you understand the failures and decide that a brief condition should not become an incident. Change one setting at a time and review the following week of history.
What to include in a support request
Include the monitor name, approximate time, affected region, and visible failure reason. Do not include passwords, complete webhook addresses, private tokens, or session cookies.
Screenshots should hide sensitive URLs and headers. Signed-in customers can open a support ticket from Support so the workspace context is attached safely.