> ## Documentation Index > Fetch the complete documentation index at: https://docs.uptimeio.com/llms.txt > Use this file to discover all available pages before exploring further. # Reading Metrics > Understand uptime, response time and check results, and read them in the dashboard UptimeIO records the result of every check. This guide explains the numbers you see for a monitor, where to find them, and how long they are kept. ## Where to find metrics | Where | What you get | | - | - | | **Dashboard overview** | A summary across your monitors: status counts, incidents and performance. | | **Monitor page** | Current status, uptime, response time graph, recent checks and incidents for one monitor. | ## Uptime percentage Uptime is the share of time a monitor was available over a period. UptimeIO calculates it by **time**, weighting each check by how long its result applied, rather than by counting checks: ```text theme={null} Uptime % = (Total time - Downtime) / Total time x 100 ``` For example, 5 minutes of downtime in 24 hours (1,440 minutes) gives (1,440 - 5) / 1,440 x 100 = **99.65%**. ### Periods The monitor page shows uptime for the time range you select. Uptime is always calculated from the data within your plan's retention period. ### What uptime figures mean | Uptime | Downtime per 30 days | | - | - | | 99.99% | about 4 minutes | | 99.95% | about 22 minutes | | 99.9% | about 43 minutes | | 99.5% | about 3.6 hours | | 99.0% | about 7.2 hours | ## Response time Response time is how long a check took to receive a response. ### Statistics * **Average**: the mean over the period. It is skewed by outliers. * **Percentiles** (p50, p90, p95, p99): the share of checks that were faster than the value. p95 of 245 ms means 95% of checks took under 245 ms. Percentiles appear in the dashboard performance metrics. ### Timing breakdown For HTTP and keyword checks, the monitor page splits the total response time into phases for each location: | Phase | Meaning | | - | - | | DNS | Time to resolve the domain | | TCP | Time to open the connection | | TLS | Time for the TLS handshake (HTTPS only) | | Server | Time to first byte: how long your server took to start answering | | Transfer | The rest of the time, spent downloading the response | Only phases that were measured are shown. A slow **Server** phase points at your application; a slow **DNS**, **TCP** or **TLS** phase points at the network or certificate setup. ## Check results The **Recent checks** list on a monitor shows the latest results: time, success or failure, response time, status code and the probe location that ran the check. The small status bars in the monitor list show the last 30 days, one bar per day. ## Reading trends * **Steady line, steady uptime**: healthy. * **Gradual rise in response time**: load is growing or resources are running out. Check CPU, memory and database performance. * **Spikes**: intermittent slowdowns. Compare the times with traffic peaks and scheduled jobs. * **Gaps or failures in one location only**: a regional or routing problem rather than an outage. Judge trends over weeks, not single data points, and set realistic targets. 99.9% (about 43 minutes of downtime a month) is a common SLA; 100% is not a useful goal. ## Data retention | Plan | Check history kept | | - | - | | Free | 90 days | | Pro | 365 days | | Scale | 365 days | Check results older than your plan's retention period are **deleted**, not archived. Note anything you need for long-term records before it ages out. ## Next steps What downtime means for your numbers Monitor settings Slow response and expiry warnings Retention by plan This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.