> ## 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, the API and exports
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. |
| **API** | `GET /api/monitors/{id}/stats`, `.../check-results` and `.../sparkline`. Accept API keys. |
## 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:
```
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 stats endpoint reports uptime over **7 days**, **30 days** (default) or **90 days**. 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 are included in response time reports and 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 (dashboard) | API field | Meaning |
| - | - | - |
| DNS | `dnsTime` | Time to resolve the domain |
| TCP | `connectTime` | Time to open the connection |
| TLS | `tlsTime` | Time for the TLS handshake (HTTPS only) |
| Server | `ttfbTime` | 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.
Through the API:
```bash theme={null}
curl "https://api.uptimeio.com/api/monitors/MONITOR_ID/check-results?limit=10" \
-H "X-API-Key: YOUR_API_KEY"
```
`limit` accepts 1 to 1,000 (default 10). Each entry has this shape:
```json theme={null}
{
"success": true,
"data": {
"results": [
{
"id": "b6a7c1d4-0a2e-4b7a-8d21-7a5f1c3e9b10",
"timestamp": "2026-09-30T10:45:00.000Z",
"status": "success",
"responseTime": 145,
"statusCode": 200
}
]
}
}
```
Failed results include an `error` message. See [Check results](/api-reference/monitors/check-results) for every field.
## Monitor statistics
```bash theme={null}
curl "https://api.uptimeio.com/api/monitors/MONITOR_ID/stats?period=30d" \
-H "X-API-Key: YOUR_API_KEY"
```
`period` is `7d`, `30d` or `90d`; any other value returns `400` with code `INVALID_PERIOD`. The response contains:
| Field | Description |
| - | - |
| `uptime_percentage` | Time-weighted uptime over the period. |
| `avg_response_time` | Average response time in milliseconds. |
| `total_checks` | Number of checks in the period. |
| `failed_checks` | Number of failed checks. |
| `last_check_at`, `last_success_at`, `last_failure_at` | Epoch timestamps, or `null`. |
| `runtime_status` | The monitor's current health: `up`, `down`, `degraded` or `unknown`. |
| `current_incident` | The open incident (`id`, `started_at`, `downtime_minutes`, `status`, `severity`), or `null`. |
See [Monitor stats](/api-reference/monitors/stats) for details. `GET /api/monitors/{id}/sparkline` returns the last 30 days as one entry per day (`timestamp`, `status`, `successCount`, `failureCount`), which is what the small status bars in the monitor list are drawn from.
## 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. Export reports before data ages out if you need long-term records.
## Next steps
What downtime means for your numbers
Monitor settings
Full endpoint reference
Retention by plan
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.