Clients ask for “a fast, reliable website” and mean three different things. Agencies then report one number and are surprised when it does not answer the question. Uptime, response time and Core Web Vitals are related, but they are measured differently, they fail differently and they need different tools.
This guide separates them, gives you the thresholds worth knowing, and says which one to watch for which problem. Parts of it are useful with no monitoring tool at all.
Uptime: is it answering?
Uptime is the share of a period in which the site answered correctly. The word “correctly” is where the arguments start. A 200 status with an error message in the page is not up in any sense a visitor would accept, which is why serious monitors check for text as well as status.
Quote downtime in minutes, because percentages hide scale:
| Uptime target | Downtime per 30-day month | Per year |
|---|---|---|
| 99% | about 7 hours 12 minutes | about 3.7 days |
| 99.5% | about 3 hours 36 minutes | about 1.8 days |
| 99.9% | about 43 minutes | about 8 hours 46 minutes |
| 99.95% | about 22 minutes | about 4 hours 23 minutes |
| 99.99% | about 4 minutes 19 seconds | about 52 minutes |
Convert your own contract number with the uptime calculator.
Three things decide whether the figure you report is honest:
- The check interval. A five-minute check cannot see a three-minute outage. Shorter intervals measure shorter outages.
- Confirmation. A single failed request is often a network blip. A good monitor re-checks before it records downtime, so the figure is not padded with false outages.
- Maintenance windows. Planned downtime should be excluded, and the exclusion should be visible in the report.
Response time: how long does the server take?
Response time is how long a request takes to be answered, measured by a monitor on a server. In Tenium the figure is the time from sending the request until the full response body has arrived, so it reflects slow database queries and large pages, not only a fast first byte.
It answers questions like “did the site get slower after the plugin update?” and “is the hosting under load at 18:00?”. It does not tell you what a visitor on a phone experiences, because no browser is involved.
Read it the right way:
- Use percentiles, not only the average. An average of 400 ms can hide a p95 of 2.5 seconds. The slow tail is what visitors complain about.
- Look at the trend. A flat 600 ms is a different site from one that creeps from 300 to 900 ms over a month.
- Know the baseline. Alert on a multiple of the normal value, not on a number you read in an article.
- Compare from the same place. Distance matters. A check from Amsterdam to a server in Amsterdam is faster than the same page for a visitor in Sydney.
On Pro and Agency, Tenium can alert when response time stays above a limit and records that as a degraded incident, separate from an outage. Every plan stores and charts the number. You can test any URL right now with the response time test.
Core Web Vitals: what does the visitor feel?
Core Web Vitals are three measurements defined by Google, taken in real browsers:
| Metric | What it measures | “Good” threshold |
|---|---|---|
| LCP, Largest Contentful Paint | When the biggest visible element appears | 2.5 seconds or less |
| INP, Interaction to Next Paint | How quickly the page reacts to clicks and taps | 200 milliseconds or less |
| CLS, Cumulative Layout Shift | How much the layout jumps while loading | 0.1 or less |
Google assesses them at the 75th percentile of real visits, and the thresholds are published on web.dev. They come from two kinds of data:
- Field data: what real visitors experienced, collected from Chrome users. This is what the Core Web Vitals report in Search Console and the field section of PageSpeed Insights show.
- Lab data: a synthetic run in a controlled browser, such as Lighthouse. Useful for finding causes, but it is a simulation.
These numbers move with images, fonts, JavaScript, third-party scripts and layout, not with how fast your server answers. A site can have a 150 ms response time and a 4-second LCP because of an unoptimised hero image.
Tenium does not run a browser, so it does not measure LCP, INP or CLS. For those, use PageSpeed Insights, the Search Console report and, for continuous measurement, a real user monitoring tool.
Which number for which problem
| Symptom | Look at | Tool |
|---|---|---|
| “The site was down last night” | Uptime, incident list | An external monitor |
| “Everything got slower since Tuesday” | Response time trend, p95 | Monitor charts, server logs |
| “The page jumps around on my phone” | CLS | PageSpeed Insights, Search Console |
| “It loads but feels stuck” | INP, LCP | PageSpeed Insights, real user monitoring |
| “Google says my pages are slow” | Core Web Vitals report | Search Console |
| “Is the checkout reachable?” | Uptime of that URL with a keyword check | An external monitor |
What to put on a client report
Keep it to a page. For each site: uptime for the month in percent and in minutes, the number of incidents with their duration and cause, average and p95 response time compared with last month, and certificate and domain expiry dates. If the client cares about search, add one line with the Core Web Vitals status from Search Console, labelled as Google’s data rather than yours.
Mixing these in one figure (“site health 94%”) invents a number nobody can verify. Report them separately and say where each comes from.
Setting thresholds
- Run the monitor for a week. Do not set alerts on day one.
- Read the response-time chart and note the normal range and the p95.
- Set the slow limit at roughly twice the normal value, and require it to be exceeded for several checks in a row.
- Keep the down alert separate. A timeout is a down, not a slow.
- Review after every major release; a heavier page moves the baseline.
On Tenium the Free plan (30 monitors, 5 min checks) already stores and charts response time. The slow-response alert needs Pro ($29), which also checks every 30 s. See the response-time monitoring page for how the threshold works, and the Tenium vs Pingdom comparison if real user monitoring is part of what you need, since Pingdom offers it and Tenium does not.
Frequently asked questions
What is a good uptime percentage?
99.9% means about 43 minutes of downtime in a 30-day month, 99.99% about 4 minutes and 99% about 7 hours. For a small business site on shared hosting, 99.9% is a realistic target; the number matters less than how quickly you learn about an outage.
What is the difference between response time and Core Web Vitals?
Response time is measured by a server somewhere requesting your URL and timing the answer. Core Web Vitals (LCP, INP and CLS) are measured in a real browser and describe what a visitor sees and feels. A fast server can still produce a poor Largest Contentful Paint.
Does Tenium measure Core Web Vitals?
No. Tenium records uptime and the time to a full response for every check, and alerts on a slow threshold on Pro and Agency. It does not run a browser, so it does not report LCP, INP or CLS. Use Google's PageSpeed Insights, Search Console and CrUX data for those.
Should I alert on response time?
Alert on a sustained slowdown, not on one slow request. Let the monitor run for a week, read the chart, and set the limit at roughly twice the normal value. A limit set at the median alerts every afternoon.
How is uptime calculated?
Time up divided by total time in the period. Planned maintenance windows can be excluded. Whether a slow response counts as downtime is a contract decision; in Tenium a degraded incident is recorded separately from an outage.
Related
Related Tenium pages
Monitor your first site free
30 monitors free, checks from 2 regions, no card. SSL and domain expiry from $7 a month.