Uptime Basics uses bounded connection fallbacks and regional confirmation to reduce false outages without hiding a real failure. These safeguards help with common HTTP, IPv4, hostname, and regional differences, but they do not bypass access controls or keep retrying beyond the monitor's configured timeout.
What the normal check does
A paid monitor checks the exact public HTTP or HTTPS URL in its settings. The request uses:
- the selected GET or HEAD method;
- the configured timeout;
- the redirect setting, with no more than five followed redirects;
- additional accepted HTTP status codes;
- supported custom request headers; and
- HTTP Basic Authentication when configured.
GET is the default for new monitors because it is accepted more consistently and tests more of the normal request path. Uptime Basics records the response time, HTTP result where one exists, and the best available failure diagnosis.
Automatic fallbacks
The service can try the following safe fallbacks when the first request does not produce a usable result.
HEAD to GET
If a paid monitor uses HEAD and receives HTTP 400, 403, 405, 406, 500, or 501, Uptime Basics can retry with GET. Some websites, CDNs, and application routes support GET but reject or mishandle HEAD.
This fallback does not make an unaccepted error code healthy. The GET result still has to meet the monitor's normal accepted-status rules.
IPv4 connection fallback
If the request has no HTTP response or times out, the service can retry through an available public IPv4 address. This can help when the hostname publishes both IPv4 and IPv6 but the IPv6 route is broken or incomplete.
The retry does not bypass DNS safety checks. Every destination must still resolve publicly and cannot be a private, local, loopback, reserved, or otherwise prohibited target.
Hostname fallback for www
If a URL beginning with www still has no HTTP result, Uptime Basics can try the equivalent hostname without www, when enough timeout budget remains.
This is a limited compatibility fallback, not a replacement for correct DNS, certificates, redirects, or virtual-host configuration. Configure the canonical URL directly once you know which hostname is intended to serve the website.
Regional confirmation
When the primary availability request fails, two additional monitoring regions can test the same monitor settings. At least two of the three regions must report failure for that check cycle to count as a region-confirmed failure.
The monitor becomes Down only after three consecutive region-confirmed failed cycles. One effective successful cycle resets the consecutive-failure count, and one successful cycle recovers a monitor that is already Down.
Fallbacks stay inside the timeout
Connection fallbacks share the monitor's configured timeout budget. They do not each receive a new full timeout.
For example, an eight-second monitor does not become a series of separate eight-second attempts. A fallback runs only when enough time remains to make it useful. This keeps the result timely and prevents compatibility attempts from delaying an outage decision indefinitely.
What Uptime Basics does not do
Uptime Basics does not:
- execute JavaScript applications or browser challenges;
- solve CAPTCHAs;
- accept cookie-consent prompts;
- complete interactive login or multi-factor authentication;
- maintain a browser session;
- bypass a firewall, WAF, geographic rule, or bot policy;
- reach private network addresses or unsupported ports; or
- inspect page content to confirm that visible text or a particular component loaded.
A challenge page that returns HTTP 200 can therefore appear Up even if a human browser would have to complete an extra step. For important applications, monitor a lightweight health endpoint designed to return an unambiguous result.
In short, Uptime Basics does not execute JavaScript or reproduce a complete browser session.
Configure a difficult target
- Use the exact canonical HTTP or HTTPS URL.
- Keep GET unless the endpoint is specifically designed for HEAD.
- Leave Follow redirects enabled when normal visitors are redirected.
- Start with the default timeout and increase it only when healthy responses legitimately need more time.
- Add an HTTP code only when that exact code is a documented healthy outcome.
- Use Custom request headers or Basic Authentication for a protected non-interactive health endpoint.
- Save the settings and review several checks in Detailed Logs.
The supported timeout choices are 5, 8, and 10 seconds. One-minute monitors have an eight-second maximum; longer intervals can use up to 10 seconds.
Prefer a purpose-built health endpoint
A health endpoint gives the clearest result when a normal webpage depends on browser JavaScript, personalization, bot controls, or large content.
A good health endpoint should:
- use public HTTPS;
- return a small response quickly;
- return a consistent successful status only when the required service is healthy;
- avoid customer data, stack traces, environment details, and secrets;
- support GET or HEAD without an interactive session; and
- use a narrowly scoped header or Basic Authentication when access must be restricted.
Do not make the endpoint report success unconditionally. It should test the minimum dependencies needed to represent real customer availability.
If the monitor still fails
Open Detailed Logs and compare the failure category, HTTP code, latency, error, and regional Confirmation. Then check DNS, CDN, WAF, load-balancer, proxy, web-server, and application logs for the same timestamp.
A response seen by only one region may indicate regional routing, DNS, or security-policy behavior. Matching failures from multiple regions are stronger evidence of a broader issue.
Contact Support when your server logs show the request should succeed but the monitor continues to fail. Include the monitor name, URL, timestamps, affected regions, diagnosis, and sanitized security-rule names. Never send passwords, custom-header values, cookies, private keys, or verification codes.