canonical: https://jentic.com/apis/hyperping.com/hyperping

# Hyperping API

The Hyperping API manages uptime monitoring and public status pages for a Hyperping project. It creates and updates HTTP, port, and ICMP monitors with a check frequency, probe regions, expected status code, and required keyword, and it runs healthchecks that expect a ping from a cron job on a fixed period or a cron expression. When something breaks, it lists detected outages and lets you acknowledge, escalate, or resolve them, open manual incidents that trigger escalation policies, and post status page incidents with timeline updates. Maintenance windows suppress alerts for chosen monitors, and monitor reports return SLA, MTTR, and outage data for a date range.

## For AI agents

Create and tune Hyperping uptime monitors and cron healthchecks, acknowledge, escalate, or resolve outages, post status page incidents and updates, schedule maintenance windows, and pull SLA and MTTR reports.

## Scope

Does not collect application logs, traces, or metrics, run synthetic browser journeys, or page people outside Hyperping escalation policies. Use for Hyperping uptime monitors, healthchecks, outages, status pages, and uptime reports only.

## Capabilities

- Create HTTP, port, or ICMP monitors with check frequency, probe regions, expected status code, and a required keyword
- Set up cron job healthchecks with a ping period or a cron expression and a grace period, and pause or resume them
- Acknowledge, unacknowledge, escalate, or resolve detected outages, filtered by status or type
- Open a manual incident with a severity that triggers an escalation policy
- Post status page incidents and add investigating, identified, monitoring, or resolved timeline updates
- Schedule maintenance windows that suppress alerts for chosen monitors and status pages
- Pull per-monitor SLA, MTTR, and outage reports for a from and to date range

## Use cases

### On-call assistant through Jentic

A developer's on-call agent watches Hyperping for ongoing outages and handles the first steps: acknowledge so escalation notifications stop, then post a status page incident. Through Jentic it finds each operation by intent, the Hyperping key is injected by the developer's own Jentic One instance, and a rule can withhold monitor deletion and status page edits.

Example prompt: Call GET `/v2/outages` with status ongoing, POST `/v2/outages/{uuid}/acknowledge` for the newest one, then POST `/v3/incidents` with type incident, a title, and the affected status page in statuspages

### Monitor setup for a new service

Add uptime coverage when a service ships. A monitor needs only a name and url, and can set protocol http, port, or icmp, the http_method, a check_frequency such as 30 or 60, probe regions such as london and frankfurt, an expected_status_code like 2xx, and a required_keyword the response must contain.

Example prompt: Call POST `/v1/monitors` with name 'Checkout API', url https://api.acme.com/health, check_frequency 60, regions ['london', 'frankfurt'], expected_status_code 2xx, and required_keyword ok

### Cron job heartbeat monitoring

Catch a backup or batch job that silently stops running. A healthcheck takes a name, a grace period, and either a simple ping period or a cron expression with a timezone, and its response includes the ping URL the job calls when it finishes; pausing it during a migration stops alerts until it is resumed.

Example prompt: Call POST `/v1/healthchecks` with name 'Daily Backup Job', cron '0 2 * * *', timezone UTC, grace_period_value 30, and grace_period_type minutes, and return the pingUrl from the response

### Monthly SLA reporting

Report uptime to customers or leadership without exporting from the dashboard. The per-monitor report call returns SLA, MTTR, and outage data, taking from and to dates in ISO 8601 and defaulting to the last 7 days when they are omitted.

Example prompt: Call GET `/v2/reporting/monitor-reports/{uuid}` for the checkout monitor with from 2026-10-01T00:00:00Z and to 2026-10-31T23:59:59Z, and report its SLA and MTTR

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/v1/monitors` | Create a monitor |
| GET | `/v2/outages` | List detected outages |
| POST | `/v2/outages/{uuid}/acknowledge` | Acknowledge an outage |
| POST | `/v2/outages/{uuid}/resolve` | Resolve an outage |
| POST | `/v3/incidents` | Create a status page incident |
| POST | `/v3/incidents/{uuid}/updates` | Add an incident update |
| POST | `/v1/maintenance-windows` | Create a maintenance window |
| GET | `/v2/reporting/monitor-reports/{uuid}` | Get a monitor's SLA and MTTR report |

## Key resources

- **Monitors** — HTTP, port, and ICMP uptime checks with frequency, regions, and assertions
- **Healthchecks** — Cron job heartbeat checks with ping URLs, grace periods, pause, and resume
- **Outages** — Detected or manual incidents with acknowledge, escalate, and resolve actions
- **Status page incidents** — Public incidents with affected components and timeline updates
- **Maintenance windows** — Scheduled windows that suppress alerts for chosen monitors
- **Status pages** — Public status pages with settings, sections, and branding
- **Monitor reports** — SLA, MTTR, and outage data per monitor

## 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:** 66 / 100
- **Maturity:** AI-Aware
- **Dimensions:**
  - Foundational Compliance: 89 / 100
  - Developer Experience & Jentic Compatibility: 61 / 100
  - AI-Readiness & Agent Experience: 50 / 100
  - Agent Usability: 94 / 100
  - Security: 60 / 100
  - AI Discoverability: 73 / 100
- **View full report:** https://jentic.com/apis/hyperping.com/hyperping/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 the Hyperping API by hand means creating a project API key, sending it as a bearer token, and keeping three API versions straight: monitors and healthchecks under /v1, outages and status pages under /v2, and status page incidents under /v3. Through Jentic you install once, import Hyperping from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Hyperping puts the monitor, outage, incident, and status page id in the URL path (`/v1/monitors/{uuid}`, `/v2/outages/{uuid}/...`), 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 monitor or a status page are not included unless you add them.
- **Credential handling:** Your Hyperping 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 'acknowledge an outage' or 'create an uptime monitor', and Jentic returns the matching Hyperping operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **UptimeRobot API** — Uptime monitoring with HTTP, keyword, ping, and port checks
- **Better Stack API** — Uptime monitoring, on-call, and status pages
- **PagerDuty API** — Incident response and on-call scheduling
- **Slack API** — Team messaging for outage notices

## FAQ

### What authentication does the Hyperping API use?

Per its OpenAPI spec, the Hyperping API uses a bearer token: an API key created on the project's developers page in the Hyperping app, sent in the Authorization header. Through Jentic the key is stored encrypted by your own Jentic One instance and injected per call.

### What is the difference between outages and incidents in the Hyperping API?

Outages, under `/v2/outages`, are the alerting side: detected or manual incidents that you acknowledge, escalate, or resolve, and that can trigger an escalation policy. Incidents, under `/v3/incidents`, are what your status page shows: a title, a type of outage or incident, affected components, the status pages it appears on, and timeline updates.

### How do I change the sections of a Hyperping status page?

PUT `/v2/statuspages/{uuid}` changes only the fields you send, except sections: when present, it replaces every section of the page. Start from GET `/v2/statuspages/{uuid}`, change what you need, and send all the sections back, or omit sections to leave them as they are.

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

The OpenAPI spec does not specify rate limits. Check Hyperping's developer documentation at https://hyperping.com for current limits.

### How do I acknowledge an outage with the Hyperping API through Jentic?

Search Jentic for 'acknowledge an outage' to get POST `/v2/outages/{uuid}/acknowledge`, find the outage id with GET `/v2/outages` filtered to status ongoing, and call it to stop further escalation notifications. To run it on your own infrastructure, install Jentic One from its GitHub repo and store your Hyperping key once.

### Is there a Hyperping MCP server?

You don't need an MCP server to give your agent Hyperping. Jentic connects it directly from the API Directory: import it, store your API key once, and your agent calls the operations you allow, discovered on demand rather than loaded into its context.

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

Yes. For example, write a rule that allows only GET `/v2/outages`, POST `/v2/outages/{uuid}/acknowledge`, and POST `/v3/incidents/{uuid}/updates`, so the agent can triage outages and post timeline updates but cannot delete monitors, edit status pages, or schedule maintenance. Your Jentic One instance logs the calls it makes.