# Hyperping MCP server

Source: https://glimind.com/server/mcp-registry%2Fcom.hyperping%2Fhyperping
Registry id: `mcp-registry/com.hyperping/hyperping`
Status: live (checked 2026-10-26T23:13:04.682Z)

## Measurements (30 days)

- Uptime: 99.97%
- Checks: 4988
- Outages (90 days): 3

## Install

```json
{
  "mcpServers": {
    "hyperping-mcp-server": {
      "type": "http",
      "url": "https://api.hyperping.io/v1/mcp"
    }
  }
}
```

Claude Code:

```sh
claude mcp add --transport http hyperping-mcp-server https://api.hyperping.io/v1/mcp
```

## Tools (69)

- `acknowledge_outage`: Mark an ongoing outage as being handled: repeat alerts stop. Escalation steps still fire on schedule; resolve it or fix the cause to stop them.
- `add_status_page_incident_update`: Post an update on a status page incident (investigating, identified, update, monitoring, resolved). Public, and sent to subscribers unless notify_subscribers is
- `add_status_page_services`: Show monitors, healthchecks, components or servers on a status page, in the section you name (created at the end if the page has none by that name) or the first
- `cancel_maintenance_window`: Cancel a maintenance window that has not started: it is deleted and leaves the status pages. Subscribers already told about it are not told it is cancelled. To 
- `complete_maintenance_window`: End a maintenance window in progress now: checks and alerts resume on its monitors and the status pages show it as completed.
- `create_log_dashboard_from_template`: Creates a log dashboard from a ready-made template (overview, errors-patterns, http-access, app-otel, containers, host-syslog, databases, jobs, ingestion-cost, 
- `create_maintenance_window`: Schedule a maintenance window: checks and alerts stop for its monitors during the window, and the status pages you pass announce it. Public once it has status p
- `create_monitor`: Create a new monitor. Requires name+url; add "port" for port checks, "dns_*" for DNS checks.
- `create_outage`: Declare an incident by hand, for a problem no monitor detects. It appears under Incident Management in the dashboard and, with an escalation policy, pages its o
- `create_status_page`: Create a status page on a hyperping.app subdomain, with sections of monitors, healthchecks, components and servers. It is public as soon as it exists: confirm t
- `create_status_page_incident`: Publish an incident on status pages, with its first update. Public, and emailed to subscribers unless notify_subscribers is false: confirm the wording with the 
- `edit_status_page_incident_update`: Correct the text or stage of an update already posted, e.g. a typo. The page shows the correction; subscribers are not notified again and its date is kept.
- `escalate_outage`: Page the next step of the outage's escalation policy now instead of waiting for it. Each call moves one step further.
- `find_correlated_outages`: Other incidents of this project that started within ±window_minutes (default 10, max 60) of an outage (outage_uuid, or incident key) or of a moment (at), each w
- `get_browser_run`: One run of a browser check (Playwright) in depth, to explain a failure: each test with its error and failed step, the script's console output, and a digest of t
- `get_escalation_policy`: One policy by UUID. Reveals step sequence, linked schedules, and contact channels.
- `get_healthcheck`: One healthcheck in detail: schedule, grace, state and timing, escalation policy, uptime and downtime over the last 30 days, its last 20 pings (pings are kept 15
- `get_integration`: One integration by UUID, with its channel-specific config (channel name, webhook URL, routing, etc.).
- `get_maintenance_window`: One maintenance window with its updates and the state of its subscriber notification.
- `get_monitor`: Fetch a single monitor by its UUID.
- `get_monitor_anomalies`: Anomaly-detection output for a single monitor (flapping, latency spikes, etc.).
- `get_monitor_http_logs`: Recent HTTP probe logs for a monitor, paginated. Useful to diagnose recent check failures.
- `get_monitor_mtta`: Mean time to acknowledge (MTTA) per monitor over a date window, in seconds. Already per-monitor — pass all monitors at once in monitor_uuids rather than calling
- `get_monitor_mttr`: Mean time to resolve (MTTR) per monitor over a date window, in seconds. Already per-monitor — pass all monitors at once in monitor_uuids rather than calling thi
- `get_monitor_outages`: Paginated list of outages scoped to one monitor. Convenience wrapper around list_outages.
- `get_monitor_response_time`: Response time latency trend over a date window. Returns a per-monitor breakdown — pass all monitors at once in monitor_uuids rather than calling this once per m
- `get_monitor_uptime`: Uptime percentage over a date window, aggregated and optionally per day/hour/week/month.
- `get_on_call_now`: Who is on call, per on-call schedule, right now or at the moment given in `at` (e.g. next Saturday 10:00), computed by the engine that pages people: names, emai
- `get_on_call_schedule`: One schedule by UUID with full rotation detail and the linked escalation policies.
- `get_outage`: Fetch a single outage by UUID, including acknowledgements, description, and root cause.
- `get_outage_alerts`: Who was notified for one outage, and how: every alert delivery attempt (time, channel email/sms/phonecall/slack/teams/webhook/pagerduty/opsgenie/…, recipient: u
- `get_outage_checks`: Region-by-region evidence for one outage ("outage_…" or an incident key like "INC-12"): a verdict — "global" (every checked region failed), "partial" (some regi
- `get_outage_logs`: Logs around one outage (incident) of the project: from 15 min before it started to 5 min after it ended. Returns warnings and errors grouped by message pattern,
- `get_outage_timeline`: Full activity timeline for an outage: detection, cross-region verification, alert dispatches, acknowledgement, resolution.
- `get_project_report`: Uptime of every monitor of the project over a period, worst first, in one call: per monitor uptime_pct, downtime (seconds + text), outage count, longest outage 
- `get_recent_changes`: What changed on a monitor before a moment (default: the outage start) and shortly after: audit-log changes to the monitor and to its escalation policies (region
- `get_server`: One server in detail: status, last seen, OS, agent version (and whether an update exists), hardware, group, tags, escalation policy; current memory and root dis
- `get_status_page`: One status page with its settings (languages, subscriptions, access) and the services it shows, section by section, with their UUIDs and type (monitor, healthch
- `get_status_page_incident`: One status page incident with every update (newest first, with their UUIDs), its status pages and affected components.
- `get_status_summary`: Up/down/paused counts plus a list of currently down monitors with the timestamp they went down.
- `list_audit_log`: Who changed what in the project (the Audit Log page; owners and admins, Business plan): newest first, each event with its time, actor (user name and email, or t
- `list_browser_runs`: Recent runs of one browser check (Playwright), newest first: when, region, pass or fail, the failing test and the first line of its error, and for checks that r
- `list_escalation_policies`: All escalation policies in the project. Use to find which monitors route alerts where.
- `list_healthchecks`: Cron/heartbeat healthchecks of the project (jobs that ping Hyperping; monitors are list_monitors, servers list_servers): per healthcheck its hc_ uuid, name, sch
- `list_integrations`: All notification integrations in the project (Slack, Telegram, Discord, PagerDuty, OpsGenie, Teams, webhook, etc.).
- `list_log_dashboards`: Log dashboards of the project: name, tags, widget count, template, last update. With `uuid`, one dashboard in detail: its time range, variables, sections and ev
- `list_maintenance_windows`: Maintenance windows, 20 per page, with their monitors, status pages, updates and status (upcoming, inprogress, completed).
- `list_monitors`: Paginated monitors in the project. Optional status filter (up/down/paused/ssl_expiring).
- `list_on_call_schedules`: All on-call schedules in the project. Each entry typically includes rotation config and current on-call.
- `list_outages`: Paginated list of outages in the project. Filter by status, type, or search term.
- `list_recent_alerts`: Alert notifications (up/down transitions) over a date range. Defaults to last 30 days.
- `list_servers`: Servers of the project (machines running the Hyperping agent, agt_ uuids; not monitors or healthchecks): per server its name, hostname, status (online, stale = 
- `list_status_page_incidents`: Incidents published on status pages, newest first, each with its current stage and latest update. For downtime detected on monitors, use list_outages.
- `list_status_pages`: Status pages in the project, 20 per page: UUID, name, public URL, password protection.
- `list_team_members`: Users on the project, with names and emails. Use to resolve user IDs from schedules/policies.
- `pause_monitor`: Pause a monitor — no checks run and no alerts fire. Same as update_monitor with paused=true.
- `remove_status_page_services`: Take monitors, healthchecks, components or servers off a status page, wherever they appear, groups included. Their settings on the page (display name, descripti
- `resolve_outage`: Resolve an incident declared by hand or a server incident, and send the recovery to the channels it paged. An outage detected on a monitor resolves itself when 
- `resolve_status_page_incident`: Close a status page incident with a final "resolved" update. Same as add_status_page_incident_update with status "resolved"; refuses an incident that is already
- `resume_monitor`: Resume a paused monitor. Same as update_monitor with paused=false.
- `run_check_now`: Run the monitor's check right now from each of its regions (20 at most) and return per region: ok, status, total ms, error, failure layer and phase timings in i
- `run_log_chart`: Aggregates the project's logs into a chart and returns a compact summary: per series min/max/avg/last and up to `max_points` points, a table (up to 50 rows) or 
- `search_logs`: Search the project's logs, newest first. Logs search language (not SQL): free words are ANDed (whole words), "exact phrase", -word to exclude, service:api, host
- `search_monitors_by_name`: Case-insensitive substring search across monitor names and URLs.
- `summarize_log_errors`: Groups the project's errors (or warnings) of a time window by message pattern (numbers, ids and IPs normalized), most frequent first: count, share, trend (>1 = 
- `update_maintenance_window`: Reschedule a maintenance window, rename it, change its monitors or status pages, or post a public update on it. The pages show the change; subscribers are not n
- `update_monitor`: Patch a monitor. Pass only fields you want to change; others are preserved.
- `update_status_page`: Change a status page's name, description, website, look or subscription button. Only the fields passed change. The page is public: confirm the change with the u
- `update_status_page_incident`: Change a status page incident's title, type, status pages or affected services. The pages show the change right away; subscribers are not notified. To tell them

Measured by Glimind (https://glimind.com): MCP handshake + tool list only, no tool is ever called. CC BY 4.0.