Check what the number includes
UpBastion measures from the beginning of the request, before DNS lookup, to the final response headers or a request error. The value includes connection setup, TLS negotiation for HTTPS, redirects and waiting for headers. The worker uses a fresh connection and does not download the full response body.
This is different from the time a visitor's browser takes to load and render a page. Images, JavaScript execution, layout and later API calls are outside the check. A low response time therefore cannot prove that the browser experience is fast, and a high check duration does not identify which request stage was slow.
The chart divides the selected period into 120 buckets and averages the durations of successful and failed checks within each bucket. A timeout can affect that average. Read response times and uptime before comparing it with a browser or application metric.
Compare like with like
Open the monitor and compare 24h, 7d and 30d where enough observations exist. Note the point when the values changed and whether failures appeared at the same time. Look for a sustained pattern across several checks rather than assigning a cause from one slower result.
Confirm that the URL stayed the same. Editing a monitor's URL keeps its old history, so a change from a static homepage to an application endpoint can create a discontinuity in the chart. A new redirect, certificate route or cache policy can also change the measured request path.
Check for missing observations. A chart bucket without checks is not a fast request. Worker interruptions and pauses affect the amount of observed time. Distinguish “we measured a delay” from “we do not have a measurement for this interval”.
Break down a local diagnostic request
The following GET request prints cumulative timing milestones. Replace the example address with the exact monitored URL. It follows at most five redirects and uses a 15-second overall limit.
curl --location --max-redirs 5 --max-time 15 \
--user-agent 'upbastion-monitor/1.0' \
--output /dev/null --silent --show-error \
--write-out 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s redirects=%{num_redirects}\n' \
'https://example.com/'The curl manual's write-out section defines these fields. They are milestones, not independent times to add together. Read them with the redirect count and the request's protocol. The total also includes transferring the response body, even though it is discarded locally; UpBastion stops at headers.
A request from your network does not reproduce the worker's DNS resolver, route or runtime. Use it to form a testable question, such as whether the same endpoint is also slow from your connection. Do not label a difference as an UpBastion error without comparing the request conditions.
Follow the evidence to the affected component
If DNS lookup is repeatedly slow in your diagnostic requests, inspect the hostname's DNS configuration and resolver behavior. If establishing a connection is slow, investigate routing, access controls and public server reachability. If waiting for response headers increases while earlier stages remain similar, inspect proxy and application request durations.
These are directions for investigation. A timing result from one machine does not prove which component was responsible for an earlier worker result. Match timestamps with the server's own logs and metrics.
For application work, check whether the endpoint waits on a database or upstream service, whether a deployment changed its behavior, and whether request volume or resource use changed. Use measured evidence from those systems. Do not assume that a high response time always means high CPU use or a slow database.
Account for caching and redirects
A cache hit and a cache miss can take different paths through your application. If you monitor a CDN-served homepage, the observed time may describe the CDN response. A dynamic readiness endpoint can include application or dependency work that the homepage avoids.
Inspect response headers and the endpoint implementation to understand its intended cache behavior. Do not add random query strings to a production monitor without knowing how the server handles them: they can change caching, increase work and create misleading comparisons.
A redirect adds requests and shares the same deadline. Prefer the canonical destination when the question is about that destination's latency. Keep a separate redirecting-address monitor only when the redirect itself is a condition you need to observe. Choosing URLs gives examples of this trade-off.
A response-time rise is not an alert condition by itself
UpBastion has no configurable response-time threshold alert. A slow response that still returns 2xx within the applicable deadlines is successful. A deadline failure can lead to a confirmed downtime incident if the next check also fails.
For browser performance, measure the browser experience separately. Web.dev's explanation of Core Web Vitals describes browser metrics such as loading, responsiveness and visual stability; UpBastion's HTTP check does not report those metrics.
After an optimization, compare the same monitored URL under comparable conditions and inspect several new observations. Record the deployment time so you can interpret the change. If there are failed requests as well as slower ones, use the downtime workflow and the troubleshooting documentation.