Hyperping MCP: Run Incidents, Status Pages and Maintenance

The Hyperping MCP server now has 49 tools: 28 that read and 21 that write. An agent connected from Claude Code, Cursor, Codex or another MCP client could already manage monitors, publish a status page incident and schedule maintenance. It can now do most of the rest: declare an incident and page on-call, acknowledge and escalate it, correct what was posted on the status page, create and configure status pages, and reschedule, end or cancel maintenance.

Key takeaways

• 13 new write tools cover incident response, status pages, status page incidents and maintenance, for 49 tools in total (28 read, 21 write).
• Five existing tools were renamed to include status_page_incident, such as create_status_page_incident. Prompts and allowlists that use the old names need updating.
• Read-only keys are refused on every write tool, and each MCP write made with an API key is recorded under that key in the project's Audit Log (Business plan).
• Nothing can be deleted over MCP, except a maintenance window that has not started yet.

Respond to incidents

The incidents of Incident Management are called outages in the API. Monitors open them on their own, and the new tools let an agent declare one by hand and act on the ones already open:

• create_outage declares an incident for a problem no monitor detects, with a title, details and a severity. Given an escalation policy, it pages that policy's on-call responders; without one, nobody is paged. It stays internal and publishes nothing on a status page.
• acknowledge_outage marks an ongoing incident as handled, which stops the repeat alerts. Escalation steps still fire on schedule until it is resolved or its cause is fixed.
• escalate_outage pages the next step of the escalation policy now instead of waiting for it. Each call moves one step further.
• resolve_outage resolves an incident declared by hand or a server incident, and sends the recovery to the channels it paged. An outage detected on a monitor resolves itself once its checks pass again.

Support says card payments fail at checkout, but every monitor is green. Declare a critical incident "Payments failing at checkout" and page the Payments escalation policy.

The agent finds the policy with list_escalation_policies, shows you what it is about to declare and who gets paged, then calls create_outage.

Acknowledge the ongoing checkout outage, I'm on it.

list_outages with status ongoing finds it, and acknowledge_outage stops the repeat alerts.

Keep customers informed

Status page incidents are what your team publishes for customers. Agents could already publish one with create_status_page_incident, post updates with add_status_page_incident_update and close it with resolve_status_page_incident, which reach subscribers by email, SMS, Slack and Teams unless notify_subscribers is false. The new tools cover the corrections that used to need the dashboard:

• update_status_page_incident changes the title, the type (incident for degraded service, outage for services down), the status pages it is published on, and the services shown as affected. The pages show the change right away and subscribers are not notified.
• edit_status_page_incident_update corrects the text or stage of an update already posted, such as a wrong region or a typo. Subscribers are not notified again and the update keeps its date.

On a page published in more than one language, each of these tools takes a language code and keeps the other translations.

Publish an incident on Acme Status: "Increased API error rates", investigating, with the API service marked as affected. Show me the text before you post it.

The agent finds the page with list_status_pages, reads its services with get_status_page, shows you the draft and the pages it targets, then calls create_status_page_incident on sp_acme.

The last update on the API incident says eu-west, but it was us-east. Fix it without notifying subscribers again, and mark the Dashboard service as affected too.

list_status_page_incidents finds inci_api_errors, get_status_page_incident returns its updates with their UUIDs, and edit_status_page_incident_update fixes the text. get_status_page gives the UUID of the Dashboard service, and update_status_page_incident adds it.

Run status pages

• create_status_page creates a page on a hyperping.app subdomain, with sections of monitors and components, a theme and an accent color. The page is public as soon as it exists. Password protection, SSO, a custom domain and a logo are still set in the dashboard.
• update_status_page changes the name, description, website link, theme, accent color, font, incident calendar, auto refresh, search engine visibility and subscription button. Only the fields passed change.
• add_status_page_services adds monitors or components to a section by its title, and remove_status_page_services takes them off the page.

A paused monitor is refused when creating a page or adding services, as in the dashboard builder: nothing checks it, so the page would show it as up.

Create a status page "Acme Status" at acme.hyperping.app with two sections: API, with the API and auth monitors, and Website, with the checkout and marketing site monitors. Dark theme, accent color #36b27e.

The agent looks up the monitors with search_monitors_by_name, confirms the name, address and services with you, then calls create_status_page.

Add the new search monitor to the API section of Acme Status and turn on the incident calendar.

list_status_pages finds the page and search_monitors_by_name the monitor. add_status_page_services adds it with section: "API", and update_status_page sets calendar: true.

Handle maintenance

create_maintenance_window already scheduled maintenance. The new tools handle the changes that come after:

• update_maintenance_window reschedules or renames a window, changes its monitors or status pages, or posts a public update on it. The pages show the change and subscribers are not notified. When a window with a scheduled subscriber notice moves, the notice keeps the lead time you chose instead of falling back to 60 minutes.
• complete_maintenance_window ends a window in progress now. Checks and alerts resume on its monitors, and the status pages show it as completed.
• cancel_maintenance_window cancels a window that has not started. It is deleted and leaves the status pages. Subscribers who were already told about it are not told it is canceled, and the result says whether they had been, so you know if they need to hear it from you.

The database migration is running late. Extend tonight's maintenance by 30 minutes and post "The work is extended by 30 minutes." on the status page.

list_maintenance_windows with timeline ongoing finds mw_db_migration, then update_maintenance_window sets the new end_date and posts the message.

We called off Saturday's payments upgrade. Cancel its maintenance.

list_maintenance_windows with timeline upcoming, then cancel_maintenance_window. A window already in progress is refused, and the agent is pointed to complete_maintenance_window.

Guardrails on writes

16 of the 21 write tools reach people outside the dashboard: status page visitors, subscribers or on-call responders. Writes come with these limits:

• Read-only API keys are refused on every write tool. The server enforces it, so no prompt gets around it. Give agents that only report a read-only key.
• All 49 tools declare MCP tool annotations: readOnlyHint and openWorldHint on every tool, plus destructiveHint and idempotentHint on the 21 writes. Clients such as Claude Code read them to decide which calls run freely and which ask you first. openWorldHint marks the writes that reach status page visitors, subscribers or on-call responders.
• The server's instructions tell agents that status pages are public, that incidents and maintenance reach subscribers by email, SMS, Slack and Teams, and that outages page on-call responders. They also ask the agent to show you the exact text and targets and wait for your go before any of these writes. The server cannot enforce this step, so keep your client's approval prompt on for these tools.
• Every successful MCP write made with an API key leaves an entry in the project's Audit Log under that key, as a REST write with the same key does. A read-only key that tries a write leaves a permission denied entry. A legacy project token leaves no API key entry, so connect agents with an API key. Audit logs are available on the Business plan.
• Deletion is not exposed, except canceling a maintenance window that has not started. Monitors, status pages, incidents and updates are deleted from the dashboard or the REST API.

Renamed tools

If you already use the Hyperping MCP server, five tool names changed. Outages now have write tools of their own, so the names say which kind of incident a tool acts on:

Their parameters are the same, and the old names no longer exist. Agents pick up the new names the next time they list the tools. Update any prompt, script or client allowlist that names the old ones, such as a Claude Code permission rule for mcp__hyperping__create_incident.

Connect an agent

The endpoint, authentication and rate limits have not changed. Create a Read/Write key under API Keys in the dashboard sidebar, export it as HYPERPING_API_KEY, and add the server. In Claude Code:

claude mcp add --transport http hyperping https://api.hyperping.io/v1/mcp \
  --header "Authorization: Bearer $HYPERPING_API_KEY"

Agent setup has the same step for Cursor, Codex, VS Code, Windsurf, Gemini CLI, Zed and Claude Desktop, and a prompt that writes the config for you. The MCP docs list every tool with its parameters, llms.txt gives agents the same reference as plain text, and the MCP server page has the overview. For read-side workflows such as triage, see 6 ways to use the Hyperping MCP server, and for uptime and MTTR reports, MCP for SLA monitoring.

Questions? Reach out via in-app chat or email us at hello@hyperping.io.