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 create, pause, and update monitors from the same conversation.

Here is what we will cover:

  1. Real-time triage: what is down and who is affected, in one question.
  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. Monitor management: creating, pausing, and updating monitors 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 a few changes.

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 read surface is wide. The write surface is deliberately small: create, update, pause, and resume monitors. There is no delete tool.

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

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.

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. Monitor management from a read_write key

With a read_write key, the agent can change configuration through conversation. The write tools are create_monitor, update_monitor, pause_monitor, and resume_monitor.

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."
  • "Pause every monitor in the staging group while we deploy, then resume them in twenty minutes."
  • "Set the timeout on the payments monitor to ten seconds."

A note on the missing delete tool: pausing is the safe default the server gives you on purpose. You can stop a monitor from alerting without losing its history, and anything destructive stays in the dashboard or REST API where it is harder to do by accident.

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(), 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.

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 tool reference live in the MCP docs.