API

Manage monitors and read uptime, checks and incidents from your own scripts: API keys, limits and endpoints.

The API lets your own scripts and tools do what you do in the dashboard: list and add monitors, change and pause them, read uptime, checks and incidents, and post incidents and maintenance to your status page. It speaks JSON over HTTPS.

API keys

Create a key under Settings → API. Give it a name and choose its access:

• Read only: GET requests only. Use this for dashboards and reports.
• Read and write: can also add, change, pause and delete monitors and post to your status page.

The key (it starts with urs_) is shown once, when you create it; we store only a hash. If you lose it, revoke it and create a new one. A revoked key stops working immediately. You can have up to 10 keys.

Send the key in the Authorization header with every request:

curl https://uptime.rs/api/v1/me \
  -H "Authorization: Bearer urs_your_key_here"

X-Api-Key: urs_… works too. Keep keys secret: anyone with a key can act on your account within its access.

Limits and usage

Each key can make 60 requests per minute and 10,000 requests per day. The daily count resets at 00:00 UTC. Requests that are refused (wrong key, over a limit) are not counted.

Every response tells you where you stand:

Over a limit you get 429 Too Many Requests with a Retry-After header (seconds). Today's usage of each key is also shown under Settings → API, and returned by GET /usage.

Requests and responses

• Base URL: https://uptime.rs/api/v1
• Send request bodies as JSON with Content-Type: application/json.
• Results are in data; lists also have meta with page, per_page, total and last_page. Ask for a page with ?page=2.
• Times are ISO 8601 in UTC, e.g. 2026-10-22T09:30:00+00:00.
• If your HTTP client or firewall only allows GET and POST, use POST …/update and POST …/delete instead of PATCH and DELETE.

Errors return a message, and for invalid input also errors per field:

HTTP/1.1 422 Unprocessable Content
{
  "message": "The selected status is invalid.",
  "errors": { "status": ["The selected status is invalid."] }
}

Account

GET /me

Your account: username, email, language, number of monitors and your status page address.

GET /usage

This key's usage today:

{
  "data": {
    "key": { "name": "Deploy script", "prefix": "urs_NPs0mwQn", "access": "read_write" },
    "requests_today": 132,
    "daily_limit": 10000,
    "remaining_today": 9868,
    "per_minute_limit": 60,
    "resets_at": "2026-10-23T00:00:00+00:00"
  }
}

Monitors

GET /monitors

Your monitors, 100 per page. Filters: status (up, down, pending, paused), q (search in name and URL), group (status page group) and per_page (1–500). Each monitor includes uptime_24h and avg_response_ms_24h.

curl "https://uptime.rs/api/v1/monitors?status=down" -H "Authorization: Bearer $KEY"

A monitor looks like this:

{
  "id": 48027,
  "name": "Example",
  "type": "http",
  "target": "https://example.com",
  "status": "up",
  "paused": false,
  "status_changed_at": "2026-10-22T02:06:10+00:00",
  "timeout_seconds": 10,
  "confirm_checks": 2,
  "slow_ms": 3000,
  "method": "GET",
  "expected_codes": null,
  "keyword": "Example Domain",
  "keyword_absent": false,
  "request_headers": null,
  "auth_user": null,
  "group_name": "Websites",
  "hide_on_status": false,
  "created_at": "2026-10-22T02:05:50+00:00",
  "url": "https://uptime.rs/monitors/48027"
}

status is pending until the first checks, then up or down, or paused. Basic auth passwords are never returned.

POST /monitors

Add one monitor with target, or many at once with targets (up to 10,000). Targets already on your account are skipped.

curl -X POST https://uptime.rs/api/v1/monitors \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"target": "https://example.com/health", "name": "API health", "keyword": "ok"}'

curl -X POST https://uptime.rs/api/v1/monitors \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"targets": ["example.com", "example.org", "db.example.net:5432"], "type": "tcp"}'

The answer lists the new monitors and counts in meta: added, invalid and already_monitored. Fields you can send (all optional except the target):

HTTP options are ignored for TCP monitors.

GET /monitors/{id}

One monitor, with uptime and average response time for the last 24 hours, 7 days and 30 days, and the latest result from each check location:

"uptime": {
  "24h": { "percent": 100, "avg_response_ms": 544 },
  "7d":  { "percent": 99.981, "avg_response_ms": 560 },
  "30d": { "percent": 99.973, "avg_response_ms": 571 }
},
"locations": [
  { "location": "fr", "ok": true, "blocked": false, "response_ms": 67, "status_code": 200, "error": "", "checked_at": "2026-10-22 02:05:58" }
]

blocked means the site's CDN or firewall refused that location; those checks do not count as downtime.

PATCH /monitors/{id}

Change a monitor. Send only the fields to change; the others keep their value. Besides the fields above you can send target and paused. Also available as POST /monitors/{id}/update.

curl -X PATCH https://uptime.rs/api/v1/monitors/48027 \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"group_name": "Websites", "expected_codes": "200-299"}'

POST /monitors/{id}/pause and /resume

Paused monitors are not checked and send no alerts; their history is kept.

DELETE /monitors/{id}

Deletes the monitor and its history. Also available as POST /monitors/{id}/delete.

GET /monitors/{id}/checks

The latest individual checks from every location, newest first. limit: 1–500, default 60.

GET /monitors/{id}/incidents

The monitor's latest 100 incidents.

Incidents

GET /incidents

Incidents across all your monitors, newest first, 100 per page. Filters: status (ongoing or resolved) and kind (down or slow).

{
  "id": 912,
  "monitor_id": 48027,
  "monitor_name": "Example",
  "kind": "down",
  "cause": "HTTP 503",
  "started_at": "2026-10-21T22:14:00+00:00",
  "resolved_at": "2026-10-21T22:19:00+00:00",
  "duration_seconds": 300,
  "ongoing": false
}

Status page

GET /status-page

Your account status page: address, title, custom domain, whether it is password protected, and the number of monitors shown and subscribers.

GET /status-page/posts

The latest 50 incidents, maintenance windows and notices posted on it, with their updates.

POST /status-page/posts

Post an incident, maintenance or notice. Subscribers are emailed within a minute, as when you post in the dashboard.

curl -X POST https://uptime.rs/api/v1/status-page/posts \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"kind": "maintenance", "title": "Database upgrade", "message": "The site may be slow for a few minutes.",
       "starts_at": "2026-10-25T02:00:00Z", "ends_at": "2026-10-25T03:00:00Z"}'

kind is incident, maintenance (needs starts_at and ends_at; alerts for the page's monitors are muted during the window) or notice.

POST /status-page/posts/{id}/updates

Add an update with a state and a message. States: for incidents investigating, identified, monitoring, resolved; for maintenance scheduled, in_progress, completed. resolved and completed close the post.

curl -X POST https://uptime.rs/api/v1/status-page/posts/3/updates \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"state": "resolved", "message": "Fixed. Everything is back to normal."}'

Example: pause everything that is down

KEY=urs_your_key_here
for id in $(curl -s "https://uptime.rs/api/v1/monitors?status=down&per_page=500" -H "Authorization: Bearer $KEY" | jq '.data[].id'); do
  curl -s -X POST "https://uptime.rs/api/v1/monitors/$id/pause" -H "Authorization: Bearer $KEY" > /dev/null
done