When something goes down, the last thing you want is to alt-tab between a monitoring dashboard, your on-call tool, and three Slack threads to figure out what is happening and who owns it. That context is usually all there. It is just scattered.

The Hyperping MCP server fixes that by putting your monitoring data inside the AI tools you already work in. Your agent can read monitor state, outage timelines, SLAs, and on-call schedules, and answer the questions you would normally chase across tabs.

Ask it what is down, who is on-call, or how your uptime looked this month, and it pulls the answer for you. With the right key it can also make changes from the same conversation: manage monitors, declare and acknowledge incidents, post updates on your status page, and schedule maintenance.

Here is what we will cover:

  1. Real-time triage and response: what is down and who is affected, then acknowledging the incident and telling customers.
  2. On-call lookup: who to page for a given monitor, without the tab-hopping.
  3. Cross-region root-cause: telling a global outage apart from a single bad region.
  4. SLA and reliability reporting: worst performers, MTTR, SSL expiry, on demand.
  5. Monitors, status pages, and maintenance: creating and changing them by chat.
  6. Combining Hyperping with your other servers for deploy correlation and shift handoffs.

What the Hyperping MCP server is

The Model Context Protocol (MCP) server lets an AI agent like Claude, Cursor, or Codex talk to your Hyperping data directly. You point the agent at https://api.hyperping.io/v1/mcp, authenticate with a project-scoped Bearer token, and the agent can read your monitoring state and, with a read_write key, make changes to monitors, incidents, status pages, and maintenance windows.

A few things worth knowing before the use cases:

  • One API key maps to one project. The scope is enforced on the server and cannot be overridden, so an agent cannot reach across projects even with a crafted monitor UUID.
  • Read-only keys block every write tool. If you want an agent that only answers questions and never touches config, give it a read-only key.
  • The server has 49 tools: 28 read and 21 write.
  • Every tool carries MCP annotations: readOnlyHint and openWorldHint on all of them, plus destructiveHint and idempotentHint on the write tools. Clients such as Claude Code read them to decide which calls run freely and which ask you first.
  • Status pages are public, their incidents and maintenance notices reach subscribers, and declared incidents page on-call responders. The server tells the agent to show you the exact text and targets before any of those writes and to wait for your go. On plans with audit logs, each successful write made with an API key leaves an ApiKeyWriteAction entry in the project's Audit Log, with the key as its target, the same as a REST write.

The product update on status pages and incidents covers the write tools added in September 2026 in more detail.

The thing I kept coming back to is that Hyperping's data is synthetic and customer-perspective. It checks your endpoints from locations worldwide every 30 seconds and verifies failures across regions before alerting. That shapes which uses are strong, which I will flag as I go.

1. Real-time triage and response

This is the use I would set up first, because it pays off in the exact moment you have no patience for digging.

Instead of opening the dashboard mid-incident, you ask the agent what is wrong and it runs the read chain for you:

  1. get_status_summary() returns counts and the list of currently-down monitors.
  2. list_outages(status: 'ongoing') pulls what is actively broken.
  3. get_outage_timeline(uuid) returns the structured event sequence: detection, cross-region verification, alerts dispatched, acknowledgment, and service restored.

Example prompts that work well:

  • "What is down right now and who is affected?"
  • "Give me the full timeline for the checkout outage."
  • "What broke in the last seven days for the payments API?"

The outage timeline is the part I would lean on. Because Hyperping verifies failures across regions, the timeline tells you whether a problem was confirmed everywhere or seen from one location. That single fact separates "our service is down" from "one region or edge node is having a bad day," and it is the difference between paging everyone and paging no one.

Responding from the same conversation

With a read_write key, the agent can also take the first steps of the response once it knows what broke:

  • acknowledge_outage(uuid) marks the incident as handled, so repeat alerts stop. Escalation steps still fire on schedule until it is resolved.
  • escalate_outage(uuid) pages the next step of the escalation policy now instead of waiting for its delay.
  • create_outage(description, escalation_policy_uuid?) declares an incident by hand for a problem no monitor catches, such as payments failing at checkout. With an escalation policy, it pages that policy's on-call responders; without one, nobody is paged.
  • resolve_outage(uuid) resolves an incident declared by hand or raised on a server, and sends the recovery to the channels it paged. An incident detected on a monitor resolves itself when its checks pass again.

These incidents stay internal. Telling customers happens on your status page: create_status_page_incident publishes the incident with its first update, add_status_page_incident_update posts the next stages as you learn more, and resolve_status_page_incident closes it with a final note. Subscribers get each update by email, SMS, Slack, or Teams unless you turn notifications off for it.

A prompt like "acknowledge the checkout incident, then draft a status page update saying we are investigating elevated errors at checkout" covers both sides. Whatever you approve goes straight to the status page and its subscribers, so read the draft before you confirm.

2. On-call lookup without the four tabs

Figuring out who to wake up usually means opening the escalation policy, following it to a schedule, reading the schedule, and matching a user ID to a name. The agent does that chain in one turn:

  1. get_monitor(uuid) to read the escalation policy.
  2. get_escalation_policy(uuid) to find the linked schedules.
  3. get_on_call_schedule(uuid) to get the current on-call user.
  4. list_team_members() to resolve the ID to a name and email.

So "who is on-call for the payments API right now?" becomes one question with one answer. Pair it with list_integrations() and the agent can also tell you where alerts for that monitor go, whether that is Slack, PagerDuty, OpsGenie, SMS, or a webhook, and flag any monitor with a weak or missing notification path.

3. Cross-region root-cause narrowing

This is the use that plays to Hyperping's strength more than any other, and it is the one I have not seen framed elsewhere because most incident tools do not have region-level synthetic data.

When response times climb or checks fail, you want to know fast whether the problem is global or local. The agent can read the cross_region_verification event from the outage timeline and combine it with get_monitor_response_time(from, to, resolution) broken out by region. From there it can answer "is this latency spike everywhere or just eu-west?" before anyone touches the application code.

get_monitor_http_logs(uuid, level: ['error']) goes one layer deeper, pulling the actual failing-check details into the conversation so you read the real error instead of a summary of it.

4. SLA and reliability reporting

Hyperping does the uptime and response-time math already. The MCP server lets an agent turn that into a report on demand or on a schedule.

  • get_monitor_uptime(from, to) returns project and per-monitor uptime. Sort the returned array by averageUptime ascending and the first entry is your worst performer this period.
  • get_monitor_mttr(from, to) and get_monitor_mtta(from, to) answer whether you are detecting and responding faster than last quarter.
  • list_monitors(status: 'ssl_expiring') filters to certificates with 0 to 30 days left.
  • get_monitor_anomalies(uuid) surfaces unusual behavior on a specific monitor.

A weekly prompt like "give me the five worst monitors by uptime this month and our MTTR trend" turns into a reliability digest you can paste into a channel. The same data backs an SLA-attainment report when a customer or an auditor asks for proof of uptime.

5. Monitors, status pages, and maintenance from a read_write key

With a read_write key, the agent can change configuration through conversation. For monitors, the write tools are create_monitor, update_monitor, pause_monitor, and resume_monitor. Status pages have create_status_page, update_status_page, add_status_page_services, and remove_status_page_services. Maintenance windows have create_maintenance_window, update_maintenance_window, complete_maintenance_window, and cancel_maintenance_window.

Prompts I would trust here:

  • "Add an HTTP monitor for api.acme.com, 30-second checks from three regions, alert if it stops returning 200 or the body loses the word ok."
  • "Put the staging monitors in a maintenance window for the next twenty minutes while we deploy."
  • "Set the timeout on the payments monitor to ten seconds."
  • "Create a status page at acme.hyperping.app with the API and checkout monitors in a section called Core services."
  • "Move Saturday's database maintenance to 03:00 UTC and add the billing monitor to it."

A status page created this way is public as soon as it exists, on its hyperping.app address. Password protection, SSO, a custom domain, and the logo are still set in the dashboard.

Rescheduling a maintenance window updates the status pages that announce it. Subscribers are not notified of the change, and a notice that has not gone out yet moves with the new start.

A note on deletion: the only thing the server deletes is a maintenance window that has not started, with cancel_maintenance_window. Subscribers who were already told about that window are not told it is canceled.

Monitors, status pages, and incidents are deleted in the dashboard or over the REST API, where it is harder to do by accident. Pausing is the safe default the server gives you on purpose: you can stop a monitor from alerting without losing its history.

There is also a config-drift use here. The agent can read every monitor's settings, compare them against a desired spec you keep in a repo, and update only the monitors that have drifted. That gives you something close to infrastructure-as-code review without leaving the chat.

6. Combining Hyperping with your other servers

Most incidents touch more than one system, so the strongest workflows connect Hyperping alongside your CI/CD, feature-flag, or observability servers and let the agent cross-reference all of it.

The clearest version is deploy correlation. When an outage timestamp lines up with a recent deploy or a feature-flag change, the agent can say something like "the payments API started failing in eu-west eleven minutes after the 14:02 deploy" without you stitching the timelines together by hand. Hyperping's outage timestamps give the agent the anchor it needs to line everything else up.

Shift handoffs are a close second. Combine list_recent_alerts(), ongoing list_outages(), any incident still open on your status page from list_status_page_incidents(status: 'ongoing'), and the current on-call data into a plain-language summary of what is still hot and who owns it, so the person picking up the shift starts with context instead of a cold dashboard.

Scheduled jobs fit the same pattern. list_healthchecks() returns each cron job's state, last ping, the time the next ping is due and a late flag while it is in its grace period, and get_healthcheck() adds its last 20 pings with run durations. A morning brief built on them answers "did last night's jobs run?", and a scheduled agent can check that the job it depends on ran before it starts. The guide to monitoring scheduled AI agents has the code for both.

Where to start

Pick the use that matches a question you already chase down by hand. If you spend incidents flipping between tabs, start with real-time triage and on-call lookup. If your week ends with a manual reliability report, start with the SLA tools. Connect it, ask the agent a question you would normally have to dig for, and expand from there.

The endpoint is https://api.hyperping.io/v1/mcp, authentication is a project-scoped Bearer token, and you can give it a read-only key the first time so the agent can look but not touch. The full setup steps and the reference for all 49 tools live in the MCP docs.