Reading Metrics

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:

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:

{
  "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 for every field.

Monitor statistics

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 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

Understanding Incidents

What downtime means for your numbers

Creating Monitors

Monitor settings

Monitor stats API

Full endpoint reference

Plans

Retention by plan

Getting Started

Monitor Types

Essentials

Notifications

Integrations

Status Pages

Account & Team

Plans & Billing

Where to find metrics

Uptime percentage

Periods

What uptime figures mean

Response time

Statistics

Timing breakdown

Check results

Monitor statistics

Reading trends

Data retention

Next steps

Understanding Incidents

Creating Monitors

Monitor stats API

Plans

​Where to find metrics

​Uptime percentage

​Periods

​What uptime figures mean

​Response time

​Statistics

​Timing breakdown

​Check results

​Monitor statistics

​Reading trends

​Data retention

​Next steps

Understanding Incidents

Creating Monitors

Monitor stats API

Plans

Where to find metrics

Uptime percentage

Periods

What uptime figures mean

Response time

Statistics

Timing breakdown

Check results

Monitor statistics

Reading trends

Data retention

Next steps