Response time
The Uptime Monitoring Response time tab shows how fast your site answered our checks, the slowest checks, and how fast it is for visitors and Googlebot.
The Response time tab of Uptime Monitoring shows how fast your site answered our checks over time. A slow climb in response time is an early warning before an outage.
Before you start
- To open the tab, select Uptime Monitoring in the domain sidebar, then select Response time.
- The tab uses the date range and the comparison of the filter bar. See Uptime Monitoring.
- The Real visitors, Googlebot and Google field data figures need RUM Monitoring, Server Log Monitoring and CrUX Monitoring.
The verdict
If some days in the date range had slow answers, the verdict of the Response time tab says Answers were slow on and names the days. The line under it gives the slowest answer on those days and the typical answer. For example: On those days, up to 2.4 s, against a typical 310 ms.
The response time card
The card at the top of the Response time tab of Uptime Monitoring has four tabs. Each tab shows its figure, and the change against the earlier period if you compare. The chart shows the figure for each hour, day or week. If you compare, the earlier period shows as a dashed line.
Typical answer
The Typical answer tab shows the median answer time of all successful checks. Sort every check from fastest to slowest and take the middle one. It is what a normal visit feels like. A rare spike does not change it.
Slowest 5% start at
The Slowest 5% start at tab shows where the slowest 5% start: the answer time that only 1 check in 20 is slower than. It shows the bad moments that the typical answer hides. The Slowest checks list below holds exactly the checks above this mark.
Slow checks
The Slow checks tab counts the checks in the slowest 5% of the date range. The note gives the number of slow days, for example 2 slow days of 28. If no day is slow, the note names the hour or the day with the most slow checks. The chart counts the slow checks and shades the slow days. The legend calls them Slow days.
A day is a slow day when one of these is true:
- Slow day (count): at least 3 slow checks, and 3 times a usual day.
- Slow day (speed): its slowest 5% start at least twice the typical answer, and 300 ms above it.
On a slow day the site was up, but visitors waited.
TTFB
The TTFB tab shows the wait for the first byte of your page. The chart splits each check into four steps:
| Step | What it is |
|---|---|
| DNS lookup | Finding the address of your server |
| Connection (TCP) | Opening the connection |
| Secure handshake (TLS) | Setting up the secure connection |
| Server wait | Your server preparing the answer |
The note names the step that takes the biggest share, for example Server wait is 83% of it. VitalSentinel times only the checks that opened a new connection. Most checks use an open connection, so TTFB is often higher than the typical answer. Before the first timed check, the tab shows No detailed timing captured yet.
How fast it feels to others
The How fast it feels to others card of Uptime Monitoring puts our check next to other sources, over the same dates. Our check reads one page from one place. The other sources read all your pages. If they are far apart, a page that our check does not ask for is slow.
| Figure | Source | What it shows |
|---|---|---|
| Our check | Uptime Monitoring | Every successful check |
| Real visitors | RUM Monitoring | TTFB in the browsers of your visitors, on all pages and devices |
| Googlebot | Server Log Monitoring | How long your server took to answer verified Googlebot |
| Google field data | CrUX Monitoring | The TTFB of Chrome users of your whole site over the last 28 days, on Phone and Desktop |
Each figure is the value that 3 out of 4 requests (or page loads) reach or do better than. The Googlebot figure can include the time to send the page, so it is not a TTFB. If a source is not connected, its figure shows Not connected and a button to connect it. If it is connected but has no data yet, it shows Waiting for data.
Slowest checks
The Slowest checks card of Uptime Monitoring lists the slowest checks of the date range, slowest first. These are the checks in the slowest 5%. Look for a pattern, for example the same hour each day.
| Column | What it shows |
|---|---|
| When | The date and time of the check. |
| Answer time | How long the checker waited: DNS lookup, connection, secure handshake and TTFB. |
| vs usual | How many times slower than the typical answer. 2× to 5× is clearly slower. 5× or more is far slower than usual. |
Each row has the menu Open this moment in. It opens the same day in another module:
- Server Log Monitoring: what Googlebot saw that day.
- RUM Monitoring: how fast it was for visitors that day.
- Google Search Console: clicks and impressions that day.
Troubleshooting
Why is the response time high but the site is up?
A high response time means that visitors wait, even if the site is up. Open the TTFB tab and find the step that takes the biggest share. If Server wait is the biggest step, your server is slow to prepare the page. If DNS lookup or Secure handshake (TLS) is big, check your DNS or certificate setup.
Why does Slowest checks say there is nothing slow?
If the card says No unusually slow checks in this window – the site stayed within its typical response time, no check was much slower than usual. This is good.
Why do Our check and Real visitors show very different figures?
Our check reads one page, often on an open connection. Real visitors open new connections on many pages and devices. If Real visitors is much slower, a page that our check does not ask for is probably slow. Look at the slowest pages in RUM Monitoring.
Why does the Response time tab show Not measured?
If the cards show Not measured or Not measured while your server refuses our checks, your server turns our checks away. Allow our monitoring in your firewall or CDN. See Monitoring IP addresses.
Related
- Uptime Monitoring - how the checks work
- Availability - uptime and every outage
- TTFB in RUM Monitoring - server response for your real visitors
- CrUX Monitoring - Google's field data for your site
- Server Log Monitoring responses - how fast your server answers bots
Availability
The Uptime Monitoring Availability tab shows your uptime, every outage, what the outages cost, and hours when Google got errors although your site looked up.
SSL and domain
The Uptime Monitoring SSL and domain tab shows when your SSL certificate and your domain registration expire, and every certificate change.
