Response time monitoring with five-phase timing

Uptimia shows whether DNS, the network or your server added the time when your site slows down. Every check runs from one of 171+ locations and is timed in five phases, from DNS lookup to the last byte received.

Start free trial → See where the time goes
30-day free trial No credit card GDPR-ready

Which phase slowed the request

Your site can answer 200 OK in 481 ms and still pass an up-or-down check. A slow server, a long network path or slow DNS can each add up to that same total.

Split into the five steps of a request, each case has a different fix. A slow server goes to the developer, who might add a missing database index. Distance calls for a CDN rule from the host, and slow DNS for a record change at the DNS provider.

What each request phase measures

A slow request spends its extra time in one step. Which step it is decides whether you call your host, your developer or your DNS provider.

  • DNS lookup Your DNS provider's phase. A jump here usually follows a record change or a problem at the provider.

    Your DNS provider

  • Connect Distance and routing. A CDN or a hosting region closer to your visitors brings it down.

    Your CDN or hosting region

  • Send The request itself. A few bytes, a few milliseconds, and it rarely moves.

    Rarely moves

  • Wait, or TTFB Time to the first byte, and the developer's phase. App code, database queries and the cache all land here.

    Your developer

  • Receive Grows when the page gets heavier or someone switches compression off.

    Page weight and compression
API monitors give the TLS handshake its own bar as well. Explore API monitoring → + TLS

Where response times appear

You'll find them on the monitor page, in the check log, on the dashboard, in scheduled reports and on status pages.

Stacked response-time chart

DNS lookup, Connect, Send, Wait (TTFB) and Receive stacked into one area, with downtime shaded red behind it. Click a legend entry to hide a phase; hover for the split at any point, with the total. Pick any date range inside your history window.

Response time and location per check

The latest checks with When, Result, Location and Response time. Click a row for the probe, the URL and the error text. The Logs page filters by monitor and status and exports CSV (name, type, location, time, status, duration) for the locations you pick.

Average response time per monitor

The dashboard table carries an average response time per monitor over the selected range, and the graph view draws a response-time sparkline per monitor. Scheduled reports list average response time beside uptime for every monitor, and a status page can show a public response-time chart.

Time each check in five phases,from 171+ locations.

Phase timing comes with every uptime check, with no agent or code to install.

Start your free 30-day trial →
30 days free no credit card cancel anytime

Get alerted on slow responses

On a website uptime monitor, the timeout decides when a hanging request becomes a failed check. API monitors also take a response-time budget on any step, so a slow step fails like a broken one. Whole-page load time is covered by the speed monitor, which alerts when pages stay slow. Each of these alerts through the same channels as an outage.

A timeout for hanging uptime checks

In the monitor's Advanced tab, the Timeout settings card holds Timeout (seconds), set to 30 by default and anywhere from 1 to 100. A check that has not finished by then counts as failed, is confirmed from other locations, and pages you like any outage. Lower it to the response time your visitors will put up with.

A millisecond budget per API step

Add an assertion to any step (Response time, under, then the budget in milliseconds). A run that overshoots fails the step, and the incident says which step and by how much. Average and p95 per step sit on the monitor page, so you can set the budget from measured times.

A page-load threshold for speed monitors

For whole-page load time, the website speed monitor alerts when the average stays slower than a threshold you set, over a window you set. It is a different monitor but uses the same alert channels.

Explore website speed monitoring →
  • Confirmation from other locations. A failed check is re-run from other locations before anyone is paged. You set how many must agree, from 1 to 3; on API monitors the first run counts as one.
  • Diagnostic details in each incident. It lists the failing location, the error, the response, headers and a traceroute.
  • Recovery notice with the duration. Everyone who was alerted gets the all-clear and how long the outage lasted.
Explore monitoring assertions → Explore API monitoring →
Recovered · all-clear to everyone alerted duration
Locations

Response times from 171+ locations

A check from your laptop measures one network in one place. Uptimia logs every reading with a checkpoint location.

  • Every check is tagged with a location. Filter the log, export the CSV and send it to whoever owns the route.
  • A slow region shows in the log. Rows from that region carry the higher times, so you can show your CDN or host where the slowdown is.
  • Phases separate distance from server load. Add a monitor that checks from one region only. Its chart shows whether the extra time sits in connect (distance) or wait (the app).
Explore multi-location monitoring →
171+ checkpoints · 70+ countries CSV

Also included

Scheduled reports

Response-time averages land in your inbox daily, weekly, monthly, quarterly or yearly. Export PDF, HTML or CSV, or hand out a public share link.

Weekly · Monday 08:00
MonitorAvg responseUptime
checkout.caldmont.com283 ms99.97%
api.caldmont.com240 ms99.98%
www.caldmont.com140 ms100%
PDF · HTML · CSV · public share link

Public status pages

Show each monitor's state and uptime percentage on a public page, served from your own domain.

status.example.com All systems operational
caldmont.com100%
api.caldmont.com99.98%

Recovery notices

The all-clear goes to everyone who was alerted, with the outage duration attached.

Checkout is DOWN14:32
Checkout is UPUP again after 14 min

Maintenance windows

Schedule a maintenance window for planned work. Checks pause while it is open, so nobody gets paged.

00:00Window · 02:00–03:0024:00
Window open → checks paused

Bulk import from a pasted list

Paste one URL per line, or url,name pairs, preview every row, and create the monitors in one batch.

https://caldmont.comhttps://shop.caldmont.com,Shophttps://api.caldmont.com… 39 more 42 rows → 42 monitors

One dashboard for everything

Phase-timed uptime checks sit next to SSL, domain, speed and server monitors in the same account, and they share one alerting setup.

www.caldmont.comUPTIME api.caldmont.comSSL web-01.caldmont.comSERVER

Example slowdowns and their settings

Each example lists the monitor settings that catch it and what Uptimia shows while it happens.

Example 1Uptime monitor

TTFB doubled after a deploy

The homepage still answers 200. On the response-time chart the Wait band steps from 180 ms to 390 ms at the minute the release went out, while DNS, connect and receive stay flat. With the network phases unchanged, the cause is in the application, such as a query that lost its index or a cache that came up cold.

Monitor settings Check intervalEvery 1 minute LocationsAll locations Timeout (seconds)30
On the chart and what happens →
On the chart
Hide every phase but Wait in the legend and the step stands out. Over the next checks, the log fills with the new number from location after location. Every location slowing alike means the server is the likely cause.
What happens
No alert fires, because the site is up. To be paged when the homepage slows, add an API monitor on the same URL with a response-time budget, as in Example 3.
Example 2Uptime monitor

One region slower than the rest

Frankfurt, London and Dallas answer in 90–230 ms, while Singapore's checks take about 470 ms. In the phase split, connect and receive are stretched and wait matches the other locations, so the server is keeping up. The Asian edge has no cached copy, and every request travels to Europe.

Monitor settings Check intervalEvery 5 minutes LocationsAll locations Timeout (seconds)30
On the chart and what happens →
On the chart
The chart is one series across all locations, so the region shows as a raised average. The check log separates it, since every row carries its location, and the CSV export filters to the locations you pick.
What happens
For separate numbers on that region, add a second monitor bound to the built-in Asia location profile, which gets a chart and average of its own. Once the CDN rule is fixed, compare that monitor's checks before and after the change.
Example 3API monitor

API p95 rising toward its budget

An orders endpoint that averages 240 ms now shows a p95 of 700 ms in the step breakdown table, up 180 ms on the previous week. That 240 ms average hides the slowest 5% of runs drifting toward the budget. The stacked-by-step chart shows which step carries the growth.

Monitor settings Check intervalEvery 1 minute AssertionResponse time · under (ms) · 800 Step timeout10 s
On the chart and what happens →
On the chart
The step breakdown lists average, p95 and the change against the previous window for every step, which gives you the figures to set the budget from.
What happens
The first run over 800 ms fails the step. Once the confirmations you set agree (this run counts as the first), an incident opens and the alert names the failing step. When the endpoint recovers, the recovery notice closes the incident with the duration.

Find the slow phaseon your own sites.

Add your URLs, and from the first check the chart shows which phase carries the time.

Start your free 30-day trial →
30 days free no credit card cancel anytime

How response time monitoring works

Uptimia checks your site from the locations you pick out of 171+ and times every request in five phases: DNS lookup, connect, send, wait and receive. Response time is their sum, charted per monitor with downtime shaded in. Each check runs from one of those locations and the log tags it, so in a slowdown the chart shows which layer grew and the log lists the locations that measured it.

01What is a good server response time?+
As a rule of thumb, under 200 ms feels instant, under 500 ms is comfortable, and past a second visitors notice. Judge it per region, since 400 ms across an ocean is mostly distance, and the same figure from a nearby location is worth raising with your developer. For the server's own share, Google's guidance rates TTFB good under 0.8 s and poor above 1.8 s.
02Do I need to install anything?+
No. Checks run from Uptimia's locations against your public URL, so there's no agent, plugin or code change.
03How does Uptimia measure response time?+
Every uptime check times DNS lookup, connect, send, wait and receive, and response time is their sum. The phases are stored with the total, which lets you trace an old slowdown later. On the chart, downtime is shaded behind them, so you can see whether timings climbed before an outage. API monitors time each step as DNS, connect, TLS, wait and receive.
04Can I get an alert when my site gets slow?+
On API monitors, a Response time assertion with an "under (ms)" budget fails the step and alerts you. Whole-page load time has its own speed monitor, which alerts when average load time stays over your threshold. Website uptime monitors only have the timeout (1–100 s, default 30, in the monitor's Advanced tab), and it turns a hanging request into a confirmed failure. A slow page that still answers within the timeout opens no incident there, though the chart shows the slowdown building.
05How do latency, TTFB, response time and page load differ?+
Latency is the network round trip, which ping measures and which is closest to the connect phase. TTFB is everything up to the first byte: DNS, connect, send and wait. Response time is all five phases, receive included. Page load covers the whole page in a real browser, scripts, images and rendering too, and website speed monitoring measures it. The free Ping test and Traceroute measure a host from the outside right now. Ping test · Traceroute · Explore website speed monitoring →
06Is a one-off speed test enough?+
A speed test gives a single reading from one location at the moment you run it. Monitoring keeps every check with its location and phase timings, so you can see when a slowdown started and whether the fix held.
07Does the chart show each location separately?+
The response-time chart is one stacked series across the monitor's locations. Per-location numbers are in the check log and the CSV export, which you can filter by location. For a region's own chart, add a monitor bound to a built-in location profile such as Europe, North America or Asia.
08Why is my site slower from some countries?+
Distance and routing, which show up in connect and receive. A CDN or a server closer to those visitors is the usual fix, and you can compare checks from those locations before and after the change.
09Can I export the timings?+
Yes. The logs CSV has name, type, location, time, status and total duration for every check, for any date range your plan's history covers. A single check exports as PDF or HTML. Scheduled reports carry average response time as PDF, HTML or CSV. The per-phase split lives in the chart.
10Which plans include response time monitoring?+
Every plan, because phase timing is part of every uptime check. The free plan watches 1 website at 5-minute intervals with 7 days of history. Paid plans keep 90 days to 2 years of history, and Professional and above check as often as every 30 seconds. The 30-day trial opens every monitor type, with no credit card.

See which layer slowed your site

Uptimia times each check in five phases from 171+ locations and alerts you when an API step or a page goes over the limit you set.

Start free trial →
30-day free trial Five timings on every check Every reading tagged with a location No credit card
Phase timing starts with your first check.