Connect Instatus to Claude: Automate Incident Reports and Maintenance

If your team needs to connect Instatus to Claude to automate incident communications, schedule routine maintenance, or manage cron monitors, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's LLM function calls and the Instatus REST API. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting Instatus to ChatGPT or explore our broader architectural overview on connecting Instatus to AI Agents.

Giving an AI agent read and write access to your public-facing status pages is a high-stakes engineering challenge. You must handle authentication lifecycles, parse deeply nested JSON schemas for page components, and navigate strict rate limit ceilings. Every time Instatus updates an endpoint or changes a payload requirement, you must update your custom server code, redeploy, and regression test the integration.

This guide breaks down exactly how to use a managed platform to generate a secure MCP server for Instatus, connect it natively to Claude, and execute complex incident management workflows using natural language.

The Engineering Reality of the Instatus API

A custom MCP server is a self-hosted integration middleware. While the open MCP standard provides a reliable protocol for models to discover tools over JSON-RPC 2.0, the reality of implementing it against specialized SaaS APIs is painful. Instatus manages highly relational data - incidents impact components, components belong to groups, and monitors trigger alerts.

If you decide to build a custom Instatus MCP server from scratch, here are the specific integration challenges your engineering team will face:

Nested Component State Management When you create or update an incident in Instatus, you often need to define how that incident impacts specific infrastructure components (e.g., setting the API to majoroutage while the Web app remains operational). An LLM has no inherent knowledge of your component IDs. You must build tools that allow the LLM to first query list_all_instatus_components, map the human-readable names to internal IDs, and then construct a strictly typed array to pass into the incident creation payload. A managed MCP server flattens these complex schemas automatically, providing clear JSON Schema validation directly to the LLM.

Cron Monitors and Secret Slugs Instatus supports cron monitors that track scheduled jobs via HTTP pings. When you create a cron monitor via the API, the response returns a slug - a unique secret used to construct the actual ping URL. If an AI agent creates a monitor, it must reliably parse this slug and communicate it back to the user or downstream system. Furthermore, cron monitors do not have a separate "pause" endpoint; you must issue an update command setting the state to PAUSED, MUTED, or ACTIVE.

Rate Limits and 429 Handling Status page APIs are heavily utilized during widespread outages, which is precisely when rate limits hit hardest. It is a critical architectural distinction that Truto does not swallow, retry, or apply backoff to rate limit errors. When the upstream Instatus API returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller (the MCP client/agent). Truto normalizes the upstream rate limit information into standardized IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). Your AI agent framework is entirely responsible for catching these errors and implementing intelligent retry and backoff logic. Do not build an integration assuming the middleware will absorb your rate limit spikes.

Generating the Instatus MCP Server

Instead of writing boilerplate Node.js or Python code to handle authentication and schema mapping, you can use a managed platform to generate a complete MCP server dynamically. The resulting server is scoped to a single integrated Instatus account and authenticated via a secure, hashed token.

You can provision this server via the user interface or programmatically via the API.

Method 1: Via the UI

For ad-hoc agent workflows or internal operations, generating the server via the dashboard is the fastest route:

1. Navigate to the Integrated Accounts page for your connected Instatus instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., restrict to read methods only, or filter by specific tool tags).
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the API

If you are provisioning AI agents dynamically for your own customers, you can generate MCP servers programmatically. The API validates the configuration, generates a secure token stored in edge storage, and returns a ready-to-use URL.

Request:

curl -X POST https://api.truto.one/integrated-account/{account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Instatus Incident Response Agent",
    "config": {
      "methods": ["read", "write"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

Response:

{
  "id": "mcp_srv_9x8y7z6",
  "name": "Instatus Incident Response Agent",
  "config": { 
    "methods": ["read", "write"] 
  },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

This URL is fully self-contained. It encodes the necessary routing and authentication to execute operations against the specific Instatus workspace.

Connecting the MCP Server to Claude

Once you have your MCP server URL, connecting it to Claude requires zero additional coding. The platform handles the JSON-RPC handshake, tool capability announcements, and schema delivery automatically.

Method A: Via the Claude UI

If you are using Claude Desktop or a managed enterprise tier that supports UI-based custom connectors:

1. Open Claude Settings.
2. Navigate to Integrations (or Connectors depending on your plan).
3. Click Add MCP Server.
4. Paste the managed URL (https://api.truto.one/mcp/...).
5. Click Add.

Claude will immediately call the tools/list protocol method and ingest the available Instatus tools.

Method B: Via Manual Config File

For developers running custom environments or local Claude Desktop instances, you can connect the server via the MCP configuration file using the Server-Sent Events (SSE) transport adapter.

Modify your claude_desktop_config.json (typically located in your OS-specific app data folder):

{
  "mcpServers": {
    "instatus-managed-server": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Restart Claude. The agent will initialize the connection and tools will appear in the UI.

Hero Tools for Instatus

A managed MCP server exposes integration endpoints as flat, strictly typed tools. By evaluating the integration's OpenAPI spec and documentation records, the platform dynamically generates tool schemas that guide the LLM on exactly what parameters to send.

Here are the most critical "hero tools" available for Instatus automation:

create_a_instatus_incident

Creates a new active incident on your status page. This tool requires the page_id and an incident name, and optionally accepts arrays to update the state of affected components.

"We just received pager alerts for database latency. Create a new incident on our production status page titled 'Investigating Database Latency' and set the status to 'investigating'."

instatus_incidents_create_from_template

Creates an incident using a predefined template. This is heavily preferred in enterprise environments to ensure consistent communication. It requires the page_id and the template ID.

"Trigger the 'DDoS Mitigation' incident template on the European status page. Ensure notifications are pushed to all email subscribers."

update_a_instatus_incident_by_id

Updates an ongoing incident to change its state, add updates, or modify the affected components. This is used continuously throughout an active outage.

"Update incident ID 109384. Change the status to 'identified' and add an update message stating 'We have isolated the degraded node and are currently failing over traffic'."

create_a_instatus_maintenance

Schedules planned maintenance. The LLM must pass a start time, duration, and the specific components that will be taken offline.

"Schedule a maintenance window for this Saturday at 2 AM UTC for 120 minutes. Name it 'Core Switch Upgrades' and mark the 'API Gateway' component as undergoing maintenance."

list_all_instatus_components

Retrieves the current state and IDs of all components on a page. This is a crucial discovery tool - the agent must run this first to learn the internal IDs before it can update component statuses during an incident.

"List all components for the US-East status page so we can identify which one represents the background worker queues."

list_all_instatus_cron_monitor_logs

Retrieves ping logs for a specific cron monitor. Useful for AI agents acting as Level 1 support to verify if scheduled jobs are failing silently.

"Check the recent logs for the 'Nightly Billing Sync' cron monitor. Have there been any missed pings in the last 24 hours?"

For the complete inventory of Instatus tools, required parameters, and pagination behaviors, view the Instatus integration page.

Workflows in Action

With the MCP server connected and tools exposed, Claude can autonomously orchestrate multi-step reliability engineering tasks. Here are two concrete workflows.

Workflow 1: Major Outage Triage & Communication

During a critical failure, manual status page updates often lag behind internal engineering Slack chatter. An AI agent can bridge this gap by querying the state, identifying the right components, and publishing the incident.

"We have a confirmed severity-1 outage affecting user logins globally. Find the 'Authentication' component, mark it as experiencing a major outage, and create a new incident titled 'Global Login Failures' with status 'investigating'."

sequenceDiagram
    participant User as User / Slack Alert
    participant Claude as Claude (Agent)
    participant MCP as Managed MCP Server
    participant Upstream as Instatus API

    User->>Claude: "Confirmed sev-1 outage on logins..."
    Claude->>MCP: Call list_all_instatus_pages()
    MCP->>Upstream: GET /v1/pages
    Upstream-->>MCP: Returns page IDs
    MCP-->>Claude: Returns pages array
    Claude->>MCP: Call list_all_instatus_components(page_id)
    MCP->>Upstream: GET /v1/{page_id}/components
    Upstream-->>MCP: Returns component list
    MCP-->>Claude: Finds ID for 'Authentication'
    Claude->>MCP: Call create_a_instatus_incident(page_id, name, components)
    MCP->>Upstream: POST /v1/{page_id}/incidents
    Upstream-->>MCP: Returns created incident
    MCP-->>Claude: Success confirmation
    Claude-->>User: "Incident 'Global Login Failures' is live. Auth component is marked offline."

What the user gets back: Claude acknowledges the alert, retrieves the necessary internal IDs dynamically, publishes the incident payload, and confirms that the public status page is reflecting the major outage.

Workflow 2: Planned Maintenance Coordination

Scheduling maintenance requires exact formatting of timestamps and component associations. Claude handles the ISO-8601 conversions and payload structuring automatically.

"We are performing database migrations next Wednesday from 11 PM to 2 AM EST. Create a scheduled maintenance for this event. Include the 'Database' and 'Reporting' components, and set them to 'under maintenance'."

1. Context Parsing: Claude parses "next Wednesday from 11 PM to 2 AM EST" and computes the correct ISO-8601 timestamps and duration in minutes.
2. Component Discovery: Claude calls list_all_instatus_components to retrieve the strict string IDs for "Database" and "Reporting".
3. Maintenance Scheduling: Claude calls create_a_instatus_maintenance, passing the computed start, duration, and the mapped components array.
4. Execution Summary: Claude returns the maintenance summary to the user, confirming that the window has been successfully scheduled and subscriber notifications are queued.

Security and Access Control

Exposing your public status page infrastructure to an LLM requires strict boundary setting. The managed MCP architecture provides multiple layers of access control at the server generation level:

• Method Filtering: Restrict servers to specific operational paradigms via config.methods. You can create a read-only server by defining ["read"] (allowing only get and list operations), preventing the LLM from accidentally mutating an active incident.
• Tag Filtering: Group tools by functional domain. By passing config.tags (e.g., ["incidents", "monitors"]), the MCP server will silently omit tools related to billing, team management, or routing rules, strictly scoping the agent's capabilities.
• Require API Token Auth: By default, the generated URL acts as a bearer token. By setting require_api_token_auth: true, you force the MCP client to pass a secondary platform API token in the Authorization header, validating both the server identity and the caller's specific session.
• Time-to-Live (TTL): Use the expires_at property to provision temporary MCP servers. Once the timestamp is reached, edge storage automatically purges the token and scheduled cleanup alarms destroy the server configurations, ensuring no stale integration access remains.

Strategic Wrap-Up

Connecting Instatus to Claude via a managed MCP server removes the friction of maintaining complex integration code, schema mapping, and API authentication. Instead of writing custom middleware to handle pagination and nested JSON structures, you can provision highly scoped, AI-ready endpoints in seconds. By providing Claude with deterministic tools, you enable your engineering and support teams to manage incidents, automate maintenance scheduling, and ensure your customers are always kept in the loop - all executed entirely through natural language.