Verify the difference before calling an alert false
An UpBastion failure means the worker could not obtain an accepted HTTP response for that check. Your browser reaching the site is useful additional evidence, but it does not erase that result. The two clients can have different network routes, sessions and access rules.
Open the monitor, note the precise error and compare the failed time with access logs. If the error is HTTP 403, find the component that returned it. If it is a timeout, establish whether the connection or application received the request. If it is a certificate error, inspect the public TLS endpoint.
A first failure schedules confirmation after 30 seconds; only a second consecutive failure opens an incident. This reduces alerts for an isolated failed observation. Both checks still come from one server, so confirmation does not establish a failure across multiple networks. Read how checks work.
Check authentication and browser challenges
UpBastion uses unauthenticated HTTP GET with User-Agent: upbastion-monitor/1.0. It does not send your browser's session cookies, solve challenges or execute JavaScript. A protected dashboard that works after you sign in is not necessarily a usable monitoring endpoint.
For an application behind Cloudflare, read how Cloudflare challenges work. A challenge can depend on browser behavior that an HTTP worker does not provide. Use your challenge and access logs to establish whether that is what happened to the check.
Choose a deliberately public endpoint when you need unauthenticated availability monitoring. A public endpoint should expose a narrow result and avoid leaking internal details. Do not put a credential in its URL to make a check work; UpBastion stores and emails the full URL.
Make narrow access changes
If your access rules block the intended monitoring request, identify the specific rule and path before adjusting it. An exception for a dedicated health endpoint is easier to reason about than a global bypass. Keep authentication on resources that actually need it.
The monitoring user agent is not an authentication mechanism. Any client can copy the header. Do not use it alone to grant access to confidential data or privileged actions. There is no published stable probe-IP list in the current UpBastion documentation, so do not invent an address range to allowlist. Contact support if your access requirements need information the documentation does not provide.
Cloudflare's user-agent blocking documentation explains one class of header-based rules. Your deployment may also have application rate limits, proxy rules or restrictions from another provider. Review the actual component that generated the response.
Treat redirects as part of the monitored path
A redirect chain can fail even when its final destination works directly. Inspect the starting URL, each Location value and the final response. The worker follows at most five redirects, validates every destination and applies one 15-second total deadline.
Prefer the canonical HTTPS URL when you need to observe the destination alone. Keep a separate monitor for an old hostname or HTTP-to-HTTPS redirect when that transition is itself needed by users. The URL planning guide explains what each monitor then proves.
A redirect to a private address, embedded credentials, a URL fragment or a custom port is rejected. A final redirect status without a usable Location header also fails. Changing the destination does not override the URL restrictions.
Represent maintenance deliberately
For planned work, decide whether you want monitoring to keep observing downtime or whether you want to pause the affected monitor. Continuing checks can record a confirmed maintenance incident and send the normal emails. Pausing stops checks and excludes paused time from observed uptime.
UpBastion does not have scheduled maintenance windows or automatic resume. If you pause, record who will resume the monitor and when. Pausing closes an open incident without a recovery email, and it does not automatically recall a notification already queued.
Do not return HTTP 200 from a broken service simply to avoid an alert. That changes the signal to success without restoring the condition you intended to observe. A maintenance response can use an appropriate error status and let the monitor record that condition, or you can deliberately suspend the observation by pausing.
Test a change without weakening the production site
After an access or redirect adjustment, run a GET against the exact public URL without your browser's session. Keep TLS verification enabled. Check the proxy or application log for the test, then wait for a new worker observation.
A working local request is a comparison from another network. A worker success is the direct verification of the monitoring path. One success closes a confirmed incident. Keep the earlier failure details until you understand which change affected the result.
If alerts remain confusing, preserve the observed timestamps, the error, the intended endpoint behavior and sanitized rule or log details. Send them through the contact form. Troubleshooting and reading HTTP failures cover the remaining request layers.