bots.st/hyperping
hyperping
Server uptime monitoring via APIs, logs, status pages
1715 ms
answered our call
- State
- Answered
- Protocol
- MCP 2025-06-18
- Tools listed
- 69
- Answered
- 3 of the last 3 calls
How to reach it
- MCP, HTTP
https://api.hyperping.io/v1/mcpNeeds header Authorization
What it can do
| Tool | What it says it does |
|---|---|
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 false. |
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 one. Services already on the page stay where they are. A healthcheck shows its uptime bar (show_uptime) but never response times. |
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 end one in progress, use complete_maintenance_window. |
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, incident-war-room, vercel). The template's fields (HTTP status, duration, route…) are detected in the project's logs; pass `bindings` to… |
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 pages: confirm with the user first. |
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 on-call responders. Internal: nothing is published on a status page (create_status_page_incident does that). |
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 the name, address and services with the user first. Password protection, SSO, a custom domain and a logo are set in the dashboard. |
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 user first. To record an incident internally and page on-call instead, use create_outage. |
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 with monitor (uuid, name), start, end or ongoing, status code, error, host, registrable domain, resolved IP and detecting region, and the… |
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 the Playwright trace (the actions up to the failure with their call log and script line, failed network requests, browser console errors… |
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 days; "start" = a /start ping without its completion, "fail" = a run the job reported failed) and its last 10 incidents (hco_ uuids… |
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 this once per monitor. |
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 this once per monitor. |
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 monitor. |
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, emails and the rotation of each person, and the escalation policies each schedule pages for. Use it for any "who is on call" question instead… |
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: user name and email, phone as its last 4 digits, or the integration name; down or up; escalation step) with its status: sent, failed (+… |
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 regions stayed healthy, listed), "single_region" or "unknown" —, the dominant failure layer (dns, connect, tls, timeout, http = the endpoint… |
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, the latest matching lines, and a per-level histogram. Works for monitor, manual, server, log-rule and healthcheck (hco_) outages. Logs… |
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 and MTTR (mean time to resolve, resolved outages only), plus project totals (average uptime, total downtime and outages, MTTR, monitors… |
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 (regions, URL, timeout, pause / resume..., with who made them; needs the owner or admin role and the plan that includes the Audit Log, like the… |
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 disk usage; last 24 h of CPU %, memory %, disk % (all filesystems) and 1-minute load as last/avg/max of 5-minute averages; filesystems… |
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, healthcheck, server or component). |
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 the API key / MCP key that acted, or system), action (e.g. UpdateMonitor, DeleteStatuspage, InviteUser, MuteOutage), resource (type, uuid… |
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 retry failures whether the retry passed. Failed runs only by default, over the last 7 days. Then read one with get_browser_run for the… |
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, schedule (cron + timezone, or period), grace period, state (down, up, or new = never pinged), paused: true when paused (no alert), last ping… |
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 every widget with its chart as HPL (run one with run_log_chart; dashboard variables such as $service must be passed in `variables`). With… |
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 = heartbeat late, offline, uninstalled), last_seen_at, OS, agent version, group, tags, current memory_pct and disk_pct of the root… |
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, description) are lost. |
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 its checks pass again. |
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 resolved. |
resume_monitor | Resume a paused monitor. Same as update_monitor with paused=false. |
And 9 more tools.
In its maker's words
Uptime, API and server monitoring with outages, reporting, on-call and status pages.
- Website
- hyperping.com/docs/mcp
- Source
- github.com/hyperping/mcp-server
- Publisher
- hyperping.com
- Listed from
- the official MCP Registry as
com.hyperping/hyperping - Version
- 1.0.0, updated 29 Jul 2026
- Kinds of work
- Cloud and DevOps, Data and databases, Browser and automation
The domain it lives on
- hyperping.io
- registered 25 Nov 2017 (8 years ago), at Cloudflare, Inc, its home page is a working site
- hyperping.com
- registered 12 Nov 2000 (25 years ago), at Cloudflare, Inc., its home page is a working site
From our own crawl of domain names: registry records and the home page as our crawler last saw it.
Every call we made
| When | What happened | Time |
|---|---|---|
| Answered | 1715 ms | |
| Answered | 1389 ms | |
| Answered | 685 ms |
Next door
Is this your bot? Claim its address to add a verified badge and keep the listing current.