Results Beta
Every check a monitor has run, newest first: whether it was up, the HTTP status, the response time, any error, and where it was checked from.
Needs an X-API-Key header whose owner has access to uptime monitoring in the app. Each call, each page included, counts once against your daily quota. See Monitoring API: getting started for authentication, rate limits and errors.
Path parameters
| Name | Type | Description |
|---|---|---|
id required | string | The monitor id, for example mon_79ce3cf9c4fa56e98af4. |
Query parameters
| Name | Type | Description |
|---|---|---|
from optional | string | integer | Start of the window, as ISO 8601 or UNIX seconds. Default: 24 hours before to. |
to optional | string | integer | End of the window, as ISO 8601 or UNIX seconds. Default: now. |
status optional | string | up or down. Leave out for both. |
region optional | string | Comma list of region codes: default (United Kingdom), na (North America), eu (Europe). Unknown codes are ignored. |
minMs optional | integer | Only checks that took at least this many milliseconds. |
maxMs optional | integer | Only checks that took at most this many milliseconds. |
page optional | integer | Page number, starting at 1. Default 1. |
per optional | integer | Results per page, 1 to 1000. Default 100. |
frommust be beforeto, and the window can be at most 92 days. For a longer period, make one request per window (see below).- Both ends of the window are included.
- When you set
minMsormaxMs, checks with no response time (for example, a connection that failed) are left out.
Request
Response
- {
- "id": "mon_79ce3cf9c4fa56e98af4",
- "from": "2026-09-10T00:00:00.000Z",
- "to": "2026-09-17T00:00:00.000Z",
- "total": 3,
- "page": 1,
- "per": 2,
- "results": [
- {
- "checkedAt": "2026-09-16T22:40:04.883Z",
- "status": "down",
- "statusCode": 502,
- "responseMs": 611,
- "error": "HTTP 502",
- "region": "default"
- },
- {
- "checkedAt": "2026-09-16T22:27:10.114Z",
- "status": "down",
- "statusCode": null,
- "responseMs": null,
- "error": "Connection refused",
- "region": "eu"
- }
- ],
- "usage": { "used": 21, "dailyLimit": 100, "tier": "free" }
- }
Response fields
| Field | Type | Description |
|---|---|---|
id | string | The monitor id. |
from, to | string | The window that was used, in ISO 8601 UTC. Useful when you relied on the defaults. |
total | integer | How many checks match, across all pages. |
page, per | integer | The page returned and the page size. |
results[].checkedAt | string | When the check ran. |
results[].status | string | up or down. |
results[].statusCode | integer | null | HTTP status, or null when no response came back. |
results[].responseMs | integer | null | Response time in milliseconds. |
results[].error | string | null | Why the check failed, such as "Connection refused", "SSL/TLS error" or a missing expected text. null when it passed. |
results[].region | string | Where the check ran from: default, na or eu. |
Results are sorted newest first. A scheduled check is only stored as down after its retries also failed, so each down result is a confirmed failure.
Errors
| Status | When |
|---|---|
400 | from or to isn't a valid date, from is after to, the window is longer than 92 days, or status isn't up or down. |
401 | Missing or invalid API key. |
403 | The key's owner doesn't have access to uptime monitoring, or the key isn't linked to a workspace. |
404 | No monitor with that id in your workspace. |
405 | A method other than GET. |
429 | A rate limit or your daily quota was hit. Read Retry-After. |
Paging through a longer period
To read everything in a period, fetch pages until you have total results. For more than 92 days, split the period into windows of 92 days or less and page through each one. Use per=1000 to keep the number of requests, and so your quota use, down: a monitor checked every 5 minutes runs about 8,640 checks in 30 days, which is 9 requests.
This script uses curl and jq to write 30 days of results to a file, one JSON object per line:
- #!/usr/bin/env bash
- set -euo pipefail
- ID="mon_79ce3cf9c4fa56e98af4"
- FROM="2026-08-18T00:00:00Z"
- TO="2026-09-17T00:00:00Z"
- PER=1000
- page=1
- : > results.jsonl
- while :; do
- resp=$(curl -fsS -H "X-API-Key: $RANKNIBBLER_API_KEY" \
- "https://www.ranknibbler.com/api/v1/monitors/$ID/results?from=$FROM&to=$TO&per=$PER&page=$page")
- printf '%s' "$resp" | jq -c '.results[]' >> results.jsonl
- total=$(printf '%s' "$resp" | jq '.total')
- echo "page $page done ($(wc -l < results.jsonl) of $total)"
- [ $((page * PER)) -ge "$total" ] && break
- page=$((page + 1))
- sleep 1 # stay well inside the burst limit
- done
Keep from and to fixed while you page. If you leave to out, it means "now" on every request, so new checks would shift the pages under you.
The same in Node.js, over several 92-day windows:
- const KEY = process.env.RANKNIBBLER_API_KEY;
- const ID = "mon_79ce3cf9c4fa56e98af4";
- const DAY = 86400 * 1000;
- async function* results(from, to) {
- for (let start = from; start < to; start = new Date(start.getTime() + 92 * DAY)) {
- const end = new Date(Math.min(start.getTime() + 92 * DAY, to.getTime()));
- for (let page = 1; ; page++) {
- const url = `https://www.ranknibbler.com/api/v1/monitors/${ID}/results` +
- `?from=${start.toISOString()}&to=${end.toISOString()}&per=1000&page=${page}`;
- const res = await fetch(url, { headers: { "X-API-Key": KEY } });
- if (res.status === 429) {
- await new Promise((r) => setTimeout(r, Number(res.headers.get("Retry-After") || 10) * 1000));
- page--; continue;
- }
- if (!res.ok) throw new Error((await res.json()).error);
- const body = await res.json();
- yield* body.results;
- if (page * body.per >= body.total) break;
- }
- }
- }
- let down = 0;
- for await (const r of results(new Date("2026-03-01T00:00:00Z"), new Date("2026-09-01T00:00:00Z"))) {
- if (r.status === "down") down++;
- }
- console.log(`${down} failed checks`);
Windows that share an edge both include a check that lands exactly on it, so you may see that one check twice. Drop duplicates by checkedAt and region if it matters.
A daily-quota 429 sets Retry-After to the seconds until midnight UTC, so for a very long backfill, check the usage object or X-RateLimit-Remaining and stop before you run out.
Related
- Get a monitor: its current status and uptime
- Outages: the outages behind the failed checks
- Performance: response times grouped by hour, day or week