When an incident opens
The first failed check schedules a confirmation after 30 seconds. It leaves the monitor pending unless it was already down. If that confirmation fails, UpBastion marks the monitor down and opens an incident. Only one incident can be open for a monitor at a time.
The incident start is the first failed observation in the confirmed sequence, not the time the confirmation finishes. Its reason is the failure recorded during confirmation, such as an HTTP error, timeout or TLS error. Different causes can occur in the same failure sequence; the reason is evidence from that check rather than a diagnosis of the underlying cause.
A single failed check followed by success creates no incident and no downtime email. The failed observation still appears in the history chart. See how checks work for the complete sequence.
While a monitor is down
Checks continue on the normal five-minute schedule after confirmation. Further failures leave the same incident open. UpBastion queues one downtime notification when the incident opens; it does not send a new downtime email for every failed check.
Open the monitor to inspect its reason, timestamp and history. Compare these observations with server logs and deployment records. Investigate a downtime alert gives a step-by-step workflow.
Recovery
One successful HTTP 2xx check closes the incident at the saved check time and queues a recovery email. Several successful checks are not required. The recorded incident duration runs from the first failed observation to the saved successful result.
An outage can begin or end between observations. The incident duration is therefore based on sampling, not a continuous measurement of all visitors' access. This matters when interpreting observed uptime.
Manual state changes
Pausing a monitor or changing its URL closes an open incident without a recovery email. These actions end the monitoring state; they do not prove the original endpoint recovered. Resuming a monitor schedules a fresh check and starts from pending.
Deleting a monitor deletes its incidents and associated queued notifications. There is no action in the current dashboard for adding an incident manually or assigning an incident to another account.
Finding older incidents
The monitor detail page lists recorded incidents. The incidents endpoint returns at most the 100 most recent records for that monitor. Daily cleanup removes closed incidents whose end time is older than 30 days; open incidents are retained.
For notification timing and retries, see email alerts. For an incident that conflicts with what you see in your own browser, use troubleshooting.