canonical: https://jentic.com/apis/realuptime.io/realuptime

# RealUptime API v1

The RealUptime API runs uptime monitoring end to end: it creates HTTP and heartbeat monitors, reads their status across probe regions, and returns time-ranged results or a Prometheus scrape target. Around the monitors it manages status pages and their published components, incidents with staged lifecycle updates, maintenance windows, and notification channels such as Discord, Teams, and Opsgenie. It also covers RealUptime Errors projects, issues, and release announcements, server capacity from installed Monitor agents, and a set of public outage readings for tracked services that need no API key.

## For AI agents

Create and inspect uptime monitors, open and update incidents on status pages, schedule maintenance windows, search error issues, and read public outage data with the RealUptime API.

## Scope

Does not page on-call engineers by phone, collect application traces, or host your website. Use for uptime monitors, status pages, incidents, and error issues on RealUptime only.

## Capabilities

- Create an HTTP monitor with a name, url, intervalSeconds, probe regions, and a latencyThresholdMs
- Read one monitor's current status aggregated across its selected regions, or time-ranged results for many check_ids
- Replace an HTTP check's response assertions on body, headers, and status range
- Open an incident on a status page for a check and region, then post updates that move it through investigating, identified, monitoring, and resolved
- Schedule a maintenance window on a status page with startsAt, endsAt, and the affected componentIds
- Publish a check as a status page component with its own displayName and description
- Search an Errors project's issues by query, release, status, and tag, and announce a release with its commitSha

## Use cases

### On-call assistant through Jentic

An on-call agent can answer 'is the API down?' and act on it: read a monitor's status, open an incident on the status page, and post updates as the fix lands. Through Jentic it searches by intent, receives the matching RealUptime operation with its input schema, and calls it while your self-hosted Jentic One instance injects the bearer key. A rule can keep it to incidents and reads, away from deleting monitors or status pages.

Example prompt: Call GET `/checks/{id}` for the failing check, then POST /incidents with its statusPageId, checkId, and region, and later POST `/incidents/{id}/updates` with status 'resolved' and a short body

### Monitors as code

Teams that keep infrastructure in version control can create and adjust monitors from a script. POST /checks requires a name and url and accepts intervalSeconds, regions, a latencyThresholdMs, and body and header assertions; PATCH `/checks/{id}` changes those later, and GET `/checks/export` downloads every check's configuration as CSV or JSON for review.

Example prompt: POST /checks with name 'Checkout API', url 'https://example.com/health', intervalSeconds 60, and two regions, then GET `/checks/{id}` to confirm it reports a status

### Status page communication

Customers read the status page during an outage. Status pages publish components backed by checks, incidents advance through a fixed status lifecycle with a body of up to 5000 characters per update, and maintenance windows announce planned work with start and end times and the components affected.

Example prompt: POST /maintenance with statusPageId, title 'Database upgrade', body, startsAt and endsAt for Saturday 22:00 to 23:00 UTC, and the affected componentIds

### Error triage by release

RealUptime Errors groups exceptions into issues per project. GET `/errors/projects/{id}/issues` searches by q, release, status, window, and tag, and GET `/errors/issues/{id}` returns releases, recent occurrences, and breadcrumbs. Announcing each deploy with POST `/errors/releases` ties new issues to the commitSha that introduced them.

Example prompt: POST `/errors/releases` with projectId, release 'v2.4.0', and commitSha, then GET `/errors/projects/{id}/issues` filtered by release 'v2.4.0' to list new issues

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/checks` | Create an HTTP monitor |
| GET | `/checks/{id}` | One monitor's current status |
| GET | `/checks/results` | Time-ranged results for checks |
| POST | `/incidents` | Open an incident on a status page |
| POST | `/incidents/{id}/updates` | Post an incident update |
| POST | `/maintenance` | Schedule a maintenance window |
| GET | `/errors/projects/{id}/issues` | Search an Errors project's issues |
| GET | `/outages/{slug}` | Public outage reading for a service |

## Key resources

- **Checks** — HTTP and heartbeat monitors with status, runs, results, and assertions
- **Status pages** — Branded status pages and their published components
- **Incidents** — Incidents against status pages with staged lifecycle updates
- **Maintenance** — Scheduled maintenance windows and Monitor agent planned work
- **Notification channels** — Discord, Teams, Opsgenie, and generic JSON alert destinations
- **Errors** — Error projects, issues, and release announcements
- **Outages** — Public outage readings and internet weather, no API key needed

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 63 / 100
- **Maturity:** AI-Aware
- **Dimensions:**
  - Foundational Compliance: 99 / 100
  - Developer Experience & Jentic Compatibility: 63 / 100
  - AI-Readiness & Agent Experience: 42 / 100
  - Agent Usability: 93 / 100
  - Security: 60 / 100
  - AI Discoverability: 64 / 100
- **View full report:** https://jentic.com/apis/realuptime.io/realuptime/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **Setup:** Wiring RealUptime by hand means sending the bearer key on account operations, knowing which outage and inbound webhook routes are open, and following the fixed incident status lifecycle yourself. Through Jentic you install once, import the RealUptime API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** RealUptime puts the check, status page, and incident ids in the URL path (`/checks/{id}`, `/status-pages/{id}/components`, `/incidents/{id}/updates`), so a rule can pin your agent to one monitor or one status page. You choose the operations it may call, so destructive ones like deleting a check or a status page are not included unless you add them.
- **Credential handling:** Your RealUptime API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'open an incident' or 'check monitor status', and Jentic returns the matching RealUptime operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **UptimeRobot** — Website and API uptime monitoring
- **Better Stack Uptime** — Uptime monitoring, on-call, and status pages
- **Statuspage** — Hosted status pages and incident communication

## FAQ

### What authentication does the RealUptime API use?

Per its OpenAPI spec, account operations use the bearerAuth scheme: an API key generated in the RealUptime dashboard sent as a bearer token in the Authorization header. Some operations are open: the endpoint index, the public outage readings, and the inbound webhooks for alerting tools, ticket trackers, and deploy platforms, which identify the account by a token or connectionId in the URL path instead. Through Jentic, your key is stored encrypted by your own Jentic One instance and injected at execution time.

### Is there a RealUptime MCP server?

You don't need an MCP server to give your agent the RealUptime API. Jentic connects it directly from the API Directory: import it, store your key once, and your agent calls it. Operations are discovered on demand, so the agent loads only the monitor or incident operation it needs instead of every tool definition.

### Can I limit what my agent is allowed to do with the RealUptime API?

Yes. An incident-comms agent could get a rule allowing GET `/checks/{id}`, POST /incidents, and POST `/incidents/{id}/updates`, so it can confirm an outage, open an incident, and post updates, while deleting checks, status pages, or notification channels stays out of reach. Every call it makes is logged.

### What are the rate limits for the RealUptime API?

The OpenAPI spec does not give numeric limits, but it documents separate read and write rate limits through the error codes RU-2002 (read rate limit exceeded) and RU-2003 (write rate limit exceeded), plus RU-2001 for too many failed authentication attempts. See https://realuptime.io/kb/errors/ru-2002 for current details.

### Can I read RealUptime outage data without an API key?

Yes. GET `/outages/{slug}` returns the public outage reading for one tracked service, GET `/outages/internet-weather` returns per-region probe latency percentiles with a 7-day baseline, and GET `/outages/internet` reports whether a named provider incident is confirmed across many services. None of these need an API key.

### How do incident updates work in the RealUptime API?

POST /incidents opens an incident against a status page and needs a statusPageId, checkId, and region. Each POST `/incidents/{id}/updates` then requires a status from investigating, identified, monitoring, or resolved and a body, advancing the incident's lifecycle on the status page.

### How do I open an incident through Jentic?

Install Jentic One with `curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh`, import the RealUptime API from the API Directory, and store your key. Your agent searches for 'open an incident on a status page', receives POST /incidents with its input schema, and calls it with the status page, check, and region. To run it on your own infrastructure, install Jentic One from its GitHub repo.