A monitor stays pending
A new or resumed monitor is due for a check, but the worker processes due monitors asynchronously. Check the dashboard for a message that checks are temporarily unavailable. Refreshing the dashboard does not trigger a check.
Pending can also mean that the first failure is waiting for confirmation. That confirmation is due after 30 seconds, with execution subject to worker availability and queue load. Compare the last-check time with check scheduling.
The URL is rejected
Use a public HTTP or HTTPS address on its default port. Remove embedded credentials, fragments and non-default ports. A hostname must resolve to accepted public addresses; names resolving to a mixture of private and public addresses are rejected.
The same rules apply after redirects. An accepted starting address can later fail if its DNS records or redirect target change. See supported URLs.
The browser works but the check fails
Your browser and the monitoring server use different networks and request contexts. Your browser can have a login session, pass a JavaScript challenge or reach a region that the monitoring server cannot. UpBastion sends an unauthenticated GET and does not execute JavaScript.
Inspect the request status and the site's access logs. A 401, 403 or 429 can point to authentication, access rules or rate limiting, but a status alone does not identify the exact rule. The monitoring request uses upbastion-monitor/1.0; this is an identification header, not a secret or proof of identity.
For Cloudflare-protected sites, review Cloudflare's challenge documentation. Make narrowly scoped access changes based on your own logs. Do not disable a site's firewall just to obtain an up result. Read monitoring through access rules.
HTTPS and certificate errors
A failed TLS handshake can prevent an HTTP status from being returned. Inspect the error and check the certificate served publicly for the exact monitored hostname. Validate the hostname, expiry date and served certificate chain.
When the URL redirects, inspect both the original endpoint and the final destination. UpBastion validates HTTPS requests on the chain, but saved expiry metadata describes the original HTTPS host.
Timeout, DNS or redirect errors
A timeout means the check reached an applicable deadline; it does not by itself distinguish a blocked connection from an application waiting on a dependency. Compare proxy and application logs for the failed interval. The entire redirect chain has one 15-second deadline.
DNS errors mean the worker could not complete a usable lookup. A redirect loop or more than five followed redirects fails. Test the exact URL, including its path and query, rather than only loading the homepage. Read HTTP failures has reproducible request examples.
The chart and incident list differ
A failed check can appear in the chart without an incident because incident creation requires confirmation. The uptime percentage subtracts confirmed downtime from observed intervals. Missing observations and paused time are excluded, so the percentage is not a continuous guarantee for the entire period.
Changing a URL retains the earlier history on that monitor. See response times and uptime before comparing values across a change.
Missing mail or a support request
Verify your primary email, check spam folders and read any dashboard mail-delivery notice. Use email alerts for the event rules and retry behavior.
If the problem remains, contact UpBastion with the monitor name, URL, approximate timestamp with timezone, observed error and the action you expected. Include a sanitized log excerpt if it helps. Do not submit passwords, access keys or unrelated customer data.