Open the monitor history
The monitor list on the dashboard shows the latest recorded request time. Select a monitor to view its current state, uptime, response-history chart and recorded incidents. Select 24h, 7d or 30d to change the history period.
The dashboard polls for new data about every 30 seconds. That refresh interval is independent of the worker's five-minute check schedule.
What response time measures
The worker starts its timer before the first DNS lookup and stops when it receives the final response headers or encounters an error. The measured time includes DNS resolution, connection setup, HTTPS negotiation where applicable, redirects and waiting for response headers.
The time is recorded in milliseconds. It is not a page-load measurement: the worker closes the response before reading the entire body, and it does not fetch images or run browser JavaScript. A request that fails can still have a measured duration, such as the time spent waiting before a timeout.
The chart groups the selected period into 120 buckets. Each bucket's response time is the arithmetic mean of its recorded check durations, including durations of failed checks. Hovering over a bucket shows its average and the number of checks represented. A bucket with no checks describes missing observations, not a successful response of zero milliseconds.
For a practical investigation workflow, read Investigate a rise in response time.
How observed uptime is calculated
UpBastion calculates uptime from observed intervals and confirmed incidents. Each saved check contributes an interval ending at the next observation, its recorded observation end, or the current time, whichever comes first. An ordinary observation covers at most five minutes. The calculation clips these intervals to the selected period and subtracts their overlap with confirmed downtime.
The formula is (observed time − confirmed downtime within observed time) / observed time × 100. It is a measure of the recorded observations, not a guarantee for every second in the selected calendar period.
For example, if there are 60 minutes of observed time and six of those minutes overlap a confirmed incident, observed uptime is 90%. This is an illustrative calculation, not a measured UpBastion service statistic.
Paused time and gaps after an observation expires are excluded. With no observed time, the result is unavailable rather than 100%. A single failed check that is not confirmed appears as a failed observation in the chart, but does not create downtime in the incident-based uptime calculation.
History retention
Check results older than 30 days are removed by the worker's daily cleanup. Closed incidents are removed when their end time is older than 30 days. An open incident stays until it is closed or its monitor is deleted. Cleanup is periodic, so removal is not guaranteed at the exact 30-day boundary.
Changing a monitor's URL retains its existing history. Keep separate monitors when you need separate statistics for different endpoints. Deleting a monitor removes its history from the active application database.
See incidents and recovery for the events that count as confirmed downtime, and account and data for deletion requests.