Website performance monitoring that measures every request step
UptimePilot measures how long your site and API take to answer, every minute from US East and EU Central. It splits each request into DNS, connect, TLS, first byte and download, keeps percentiles instead of misleading averages, and marks a monitor as degraded when it gets slow, before it goes down.
Response time monitoring per region
A site that answers in 180 ms from a nearby city can take 900 ms from the other side of an ocean. Visitors from both places count. Every HTTP, keyword and API check in UptimePilot records the response time separately for each region, so you see the difference and can tell a global slowdown from a regional one. If both regions get slower at the same minute, the cause is almost always the origin: a deploy, a database under load, an exhausted cache. If only one region gets slower, look at the network path, a CDN edge or DNS in that part of the world.
Timing breakdown of every check
Total response time is a sum of steps, and each step has a different owner. UptimePilot stores all of them for every check.
- DNS lookup. Resolving the hostname. Usually under 50 ms with a healthy resolver; spikes point to the DNS provider or a very low TTL.
- Connect. TCP handshake to the server or CDN edge. Roughly one network round trip, so it grows with distance.
- TLS. Negotiating encryption and validating the certificate chain. A long chain, missing session resumption or a slow certificate status lookup show up here.
- First byte. Time from sending the request to the first byte of the answer. This is your application: code, database queries, cache misses, cold workers after a deploy.
- Download. Time to receive the rest of the response. Large uncompressed HTML or JSON makes this grow.
When first byte doubles and everything else stays flat, the conversation goes to the application team, not the network team. That saves the first twenty minutes of every slowdown investigation.
Percentiles p50, p95 and p99 instead of averages
An average hides the visitors who suffer. If 95 requests take 200 ms and 5 take 4 seconds, the average is 390 ms and looks fine, while one visitor in twenty waits four seconds. UptimePilot reports percentiles for every monitor and period.
- p50, the median. Half of checks were faster than this. It describes a normal moment.
- p95. 95 percent of checks were faster. It shows how bad the slow moments get, and it is the number most performance targets use.
- p99. 99 percent were faster. It catches rare stalls, lock waits and garbage collection pauses that p95 still hides.
A healthy API often has p50 near 150 ms and p95 under 500 ms. A gap between p50 and p99 that keeps growing week after week is an early sign of a database or queue that is running out of room.
Slow thresholds and the degraded state
Slow is not the same as down, but customers feel it first. For each monitor you set a slow threshold, for example 1,500 ms for a page or 800 ms for an API endpoint, and how many checks in a row must exceed it. When they do, and the second region agrees, the monitor moves to a degraded state. You choose whether degraded alerts anyone, posts only to a Slack or Microsoft Teams channel, or simply shows on the dashboard. The timeout (the point where slow becomes down) stays separate, so a request that never answers is still treated as an outage with a full alert and escalation.
Charts and reports for website performance monitoring
Each monitor has a response time chart with the region lines and the timing steps stacked, for the last hour, day, week or month. Reports summarise uptime percent and p50, p95 and p99 response time per monitor, so you can compare this month with the last one and see the effect of a release. On Team and above, the monthly SLA PDF includes response time percentiles next to uptime. On Business, agencies send white-label client reports with the same data. More on uptime monitoring service reports.
What this website performance monitoring does not include
UptimePilot measures response time from monitoring regions with scheduled checks. It does not do real user monitoring, so it does not collect timings from your visitors' browsers. It does not render pages, so it does not report paint, layout or script metrics. That keeps it honest and stable: every number comes from the same kind of request, every minute, which makes trends and comparisons reliable. If you also need in-browser metrics, run them next to UptimePilot.
Where response time fits in your monitoring
Response time comes with every website monitoring and api monitoring check, including assertions on the JSON body. For a quick one-time measurement of a URL, run a website uptime test. To get alerts when speed turns into an outage, see website downtime tracker.
Which plan fits your performance tracking
All plans record response time, timing breakdown and percentiles. History and interval decide how far back and how fine your charts are.
- Starter, $49 a month or $24 a month billed yearly. 50 monitors, 1 minute checks, 90 days of history, uptime and response time reports.
- Team, $99 a month or $49 a month billed yearly. 200 monitors, 30 second checks, 1 year of history, monthly SLA PDF.
- Business, $249 a month or $124 a month billed yearly. 1,000 monitors, 2 years of history, white-label client reports and REST API.
- Enterprise, $599 a month or $299 a month billed yearly. 3,000 monitors, 3 years of history, SSO (SAML) and audit log.
Yearly billing saves 50 percent. Details on uptime monitoring pricing.
01
Why do my response times differ between regions?
Connect and TLS take about one network round trip each, which grows with distance. Compare first byte across regions: if it matches, the difference is network, not your server.
02
Which percentile should I set a target on?
p95 is the usual choice for a target. Watch p99 for rare stalls and p50 for the normal experience.
03
What is the difference between degraded and down?
Degraded means the monitor answers but slower than your threshold. Down means it fails or exceeds the timeout. Both are confirmed by a second region.
04
Does UptimePilot measure page rendering or real visitors?
No. It measures the server response with scheduled checks from monitoring regions. It does not run real user monitoring or measure rendering.
05
How long is response time history kept?
90 days on Starter, 1 year on Team, 2 years on Business and 3 years on Enterprise.
See where every millisecond goes
Add a URL or API endpoint and get the first timing breakdown within a minute.