Categories › Cloud & DevOps › Monitoring, logs & incidents
Uptime, API and server monitoring with outages, reporting, on-call and status pages.
Remote server: your requests and data go to api.hyperping.io. Claude Code: claude mcp add --transport http hyperping https://api.hyperping.io/v1/mcp · Claude app: Settings → Connectors → Add custom connector.
The tools this server listed when we connected to it, in its own words.
list_monitors — Paginated monitors in the project. Optional status filter (up/down/paused/ssl_expiring).get_monitor — Fetch a single monitor by its UUID.create_monitor — Create a new monitor. Requires name+url; add "port" for port checks, "dns_*" for DNS checks.update_monitor — Patch a monitor. Pass only fields you want to change; others are preserved.pause_monitor — Pause a monitor — no checks run and no alerts fire. Same as update_monitor with paused=true.resume_monitor — Resume a paused monitor. Same as update_monitor with paused=false.search_monitors_by_name — Case-insensitive substring search across monitor names and URLs.get_status_summary — Up/down/paused counts plus a list of currently down monitors with the timestamp they went down.list_outages — Paginated list of outages in the project. Filter by status, type, or search term.get_outage — Fetch a single outage by UUID, including acknowledgements, description, and root cause.get_outage_timeline — Full activity timeline for an outage: detection, cross-region verification, alert dispatches, acknowledgement, resolution.get_monitor_outages — Paginated list of outages scoped to one monitor. Convenience wrapper around list_outages.create_outage — Declare an incident by hand, for a problem no monitor detects. It appears under Incident Management in the dashboard and, with an escalationacknowledge_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 thescalate_outage — Page the next step of the outage's escalation policy now instead of waiting for it. Each call moves one step further.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 rlist_recent_alerts — Alert notifications (up/down transitions) over a date range. Defaults to last 30 days.get_monitor_uptime — Uptime percentage over a date window, aggregated and optionally per day/hour/week/month.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 calget_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 ratget_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_uuidsget_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.list_on_call_schedules — All on-call schedules in the project. Each entry typically includes rotation config and current on-call.get_on_call_schedule — One schedule by UUID with full rotation detail and the linked escalation policies.list_escalation_policies — All escalation policies in the project. Use to find which monitors route alerts where.get_escalation_policy — One policy by UUID. Reveals step sequence, linked schedules, and contact channels.list_team_members — Users on the project, with names and emails. Use to resolve user IDs from schedules/policies.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 pageslist_integrations — All notification integrations in the project (Slack, Telegram, Discord, PagerDuty, OpsGenie, Teams, webhook, etc.).get_integration — One integration by UUID, with its channel-specific config (channel name, webhook URL, routing, etc.).list_status_pages — Status pages in the project, 20 per page: UUID, name, public URL, password protection.get_status_page — One status page with its settings (languages, subscriptions, access) and the services it shows, section by section, with their UUIDs and typcreate_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 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 tadd_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 tharemove_status_page_services — Take monitors, healthchecks, components or servers off a status page, wherever they appear, groups included. Their settings on the page (dislist_status_page_incidents — Incidents published on status pages, newest first, each with its current stage and latest update. For downtime detected on monitors, use lisget_status_page_incident — One status page incident with every update (newest first, with their UUIDs), its status pages and affected components.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 tNot tested by KitScout yet. When our harness runs it, pros, cons and the tasks we tried appear here, with the date and evidence.