Capture the observation before changing anything
Start with the downtime message and the monitor detail page. Record the monitor name, full URL, first failed observation, confirmation result and error. Include the timezone when comparing those times with your own logs.
UpBastion opens an incident after a second consecutive failure. Its start is recorded at the first failed observation. The actual outage can have begun earlier between checks. An email can also arrive later than the incident because delivery runs through a separate queue. Read incidents and email timing before using the email arrival time as an outage timestamp.
Keep a short record of each observation and action. If several people are investigating, identify which component each person is changing. Avoid making several unrelated changes before checking whether any of them affected the result.
Establish the scope
Check the exact monitored address from your own network and inspect the other monitors you maintain. Determine whether the homepage, API and a public health endpoint are failing together or independently. These observations narrow the investigation but do not prove a root cause on their own.
Use an unauthenticated request and keep HTTPS certificate validation enabled. A signed-in browser can hide an access difference. An HTTP monitor also does not run JavaScript, so a website that fails after its first document loads can remain green.
Checks come from one UpBastion server. A failure from that server is evidence about its request, not a measurement from every region. Likewise, a successful request from your laptop does not establish reachability for the worker. Compare the request context instead of dismissing one result.
Check DNS and the destination
If the error concerns name resolution, inspect the hostname's DNS records and any recent DNS changes. Look for misspellings, missing records, unexpected destinations and differences between the records you expect and the records returned by a resolver.
For example, dig example.com A and dig example.com AAAA inspect the public address records when the dig utility is available. Replace the example hostname. A lookup performed from your computer is evidence from your resolver at that time, not a replay of the worker's earlier lookup.
UpBastion rejects a hostname when any resolved address is private or reserved. A changed DNS record can therefore break monitoring even if another address still serves the website. Read URL restrictions before assuming every DNS result is accepted.
Check HTTPS before the application
A TLS error can stop a request before an HTTP status exists. Inspect the certificate served for the exact hostname. Check its validity dates, hostname coverage and the chain presented by the public server or CDN.
An illustrative inspection command is:
openssl s_client -connect example.com:443 -servername example.com \
-verify_hostname example.com -verify_return_error </dev/nullThe OpenSSL s_client documentation explains the flags. Your machine's trust store and OpenSSL version can differ from the worker's runtime. Use the output to inspect a condition, not to claim both environments are identical.
If there is a redirect, inspect every HTTPS host in the chain. The monitor's saved expiry date describes its original HTTPS host. It does not certify the health of every destination. TLS monitoring covers these limits.
Find which layer produced the response
When a status code exists, check response headers and access logs to identify whether the CDN, reverse proxy or application handled the request. Search for the request path and the monitoring user agent upbastion-monitor/1.0 around the recorded time.
A 403 can indicate an access rule. A 502 or 504 can indicate a gateway problem talking to its upstream. A 500 can reflect application failure. Treat these as investigation paths and confirm them in logs. Read HTTP failures explains why the code alone is not a root-cause report.
For a timeout, inspect whether the request reached the public proxy and the application. An absent application log can be useful, but logging configuration and retention also affect what you can see. Do not infer that the application never received a request solely because a log search returned nothing.
Compare the failure with recent changes
Review deployments, configuration edits, certificate changes and DNS changes near the observation. Check dependency errors at the same time. A database connection failure, unavailable upstream or exhausted application resource needs direct evidence from the affected component.
Choose a recovery action supported by that evidence. Rolling back a deployment is appropriate only when you understand what the rollback restores, including configuration and database compatibility. Restarting a component can change the symptom without explaining the fault; retain relevant logs first when your tools allow it.
For access-rule problems, change only the relevant rule or endpoint. Do not broadly bypass authentication or firewall checks. The access and maintenance guide covers that choice.
Verify recovery and keep the useful evidence
After a fix, test the same public request again. Then wait for a successful UpBastion observation. One success closes the incident and queues a recovery email. Subsequent observations and application logs help you see whether the condition stays resolved.
Pausing a monitor or changing its URL also closes an incident, but does so without proving recovery and without a recovery email. Avoid using those actions merely to clear a red result.
Keep the observation sequence, the confirmed cause where known, the recovery action and any follow-up in your own incident record. Check history is retained for 30 days with daily cleanup, so copy the evidence you need before it ages out. If UpBastion's behavior remains unclear, contact us with timestamps and sanitized evidence.