The HTTP request
The worker resolves the monitored hostname, checks that all returned addresses are public and connects to one accepted address. It prefers an IPv4 address when one is returned. The connection uses the resolved address directly for that request while retaining the hostname for HTTP and TLS.
The request uses HTTP GET with User-Agent: upbastion-monitor/1.0 and Accept: */*. It starts a fresh connection for each request. HTTPS certificate validation is enabled. UpBastion reads the response status and headers, then closes the response without downloading and examining the complete body.
The check does not run JavaScript, retain login cookies, load images or execute browser interactions. Public endpoints needing a browser challenge, session cookie or authentication header cannot be checked as an authenticated visitor.
Success and failure
Only a final HTTP status from 200 through 299 counts as success. Every other final status counts as failure. DNS resolution errors, rejected addresses, TLS validation errors, connection errors and request timeouts are failures even when no HTTP status is available.
A check has a 15-second total deadline across DNS lookups and redirects. A DNS lookup is limited to at most five seconds of the remaining deadline. The connection also has a 10-second inactivity timeout, so a check can fail before the total deadline is reached.
Use HTTP failures to distinguish a returned error status from a failure that occurred before an HTTP response.
Redirects
UpBastion follows responses in the 300–399 range when they include a Location header. It follows at most five redirects and evaluates the final response. A chain ending in HTTP 200 succeeds; a final 301 without a Location header fails. Relative Location values are resolved against the current URL.
Every redirect target must meet the same URL requirements as the original URL. A redirect to a private address, credentials, a fragment or a custom port fails the check. Redirects share the original 15-second deadline.
Scheduling and confirmation
After a normal check is saved, the next check is scheduled five minutes later. After the first failure, a confirmation check is scheduled 30 seconds later. These are due times, not promises of execution to the exact second. Request duration, queue load and worker availability can add delay.
If the confirmation succeeds, the monitor returns to up without an incident or downtime email. If it fails, the monitor becomes down, an incident opens and a downtime email is queued. Further failed checks on that open incident do not each generate another downtime email. One successful check is enough to close the incident.
For example, a failed result saved at 12:00:00 is due for confirmation at 12:00:30. If that confirmation fails, the incident start is recorded as 12:00:00. The actual outage might have started between earlier checks; the timestamp is an observation, not proof of the exact failure time.
Where observations come from
Checks run from one server. UpBastion does not provide a choice of probe location or confirmation from several regions. A failed check describes reachability from that server; it does not establish that every visitor in every network was unable to reach the site.
Outages that start and end between checks can go unobserved. A worker interruption creates a gap in observations. Read uptime and history, incidents and troubleshooting for how those gaps and states appear.