Instatus
Instatus is a status page and incident communication platform for managing service health, incidents, maintenance, monitors, and subscribers.
Verdict
Common use cases
- Declare an outage and notify customers instantly
- Post incident updates as you troubleshoot live
- Schedule maintenance windows with subscriber alerts
- Mark components degraded during partial failures
- Close resolved incidents and restore component health
Integration
- Vendor
- Instatus
- Category
- other
- Auth
- API_KEY
- Tools
- 15
- Composio slug
instatus
Tools
- Add Incident Update
Post a public lifecycle update to an Instatus incident and change affected component states. This can send external notifications to page and affected-component subscribers when notify is true.
- Add Maintenance Update
Post a public progress update to an Instatus maintenance, optionally changing its lifecycle, timing, and affected component states. This can send external notifications to page and affected-component subscribers when notify is true.
- Create Component
Create a component on an Instatus status page. This changes the page's component configuration and can make the new component and its initial health status publicly visible.
- Create Incident
Create an incident on an Instatus status page with optional affected component states. The incident is published publicly by default; notify=true can send notifications to page and affected-component subscribers.
- Create Maintenance
Schedule or start a maintenance on an Instatus status page. The required notification controls are side-effecting: notify can contact subscribers immediately, while notify_start, notify_end, and notify_early schedule later subscriber notifi
- Get Component
Get the current health and configuration of one component on an Instatus status page.
- Get Incident
Get one Instatus incident with its affected components and update history.
- Get Maintenance
Get one Instatus maintenance with its schedule, affected components, automation settings, and update history.
- List Components
List components and their current health for one Instatus status page, including child components where present. Pass the response's next_cursor back unchanged to fetch another page.
- List Incidents
List incidents for an Instatus status page, optionally including or excluding lifecycle statuses.
- List Maintenances
List scheduled and historical maintenances for an Instatus status page.
- List Status Pages
List status pages available to the connected Instatus account so an agent can discover page IDs for component, incident, and maintenance operations.
- Update Component
Change a component's health or presentation on an Instatus status page.
- Update Incident
Edit an existing Instatus incident's name, timing, lifecycle status, affected components, or component states. Setting notify to true sends notifications to page and affected-component subscribers.
- Update Maintenance
Fully replace an Instatus maintenance's public message, schedule, lifecycle state, affected components and states, and automation settings. Call INSTATUS_GET_MAINTENANCE first and preserve unchanged values; setting notify to true sends subs
Setup
Setup guide
- 11. Open your Switchy workspace and navigate to Settings > Integrations. 2. Find Instatus in the MCP catalog and click Connect. 3. Log in to your Instatus dashboard, go to Settings > API, and generate a new API key with full read-write access. 4. Paste the key into Switchy's auth prompt and click Authorize. 5. Switchy will confirm the connection and show which status pages the key can access. 6. Open any Project, type '@Instatus list all components' and send the message. 7. If the MCP returns a list of your page's components with their current health states, the connection works. 8. To invoke a tool in a real scenario, @mention Instatus and describe the task in plain language — for example '@Instatus create an incident for the API gateway, mark it investigating, and notify subscribers'.
What teammates see: by default, memories from Instatus are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
Report New Outage
@Instatus create an incident titled 'API Gateway Unavailable' with status investigating, mark the API component as major outage, and notify all subscribers
Post Progress Update
@Instatus add an update to incident #12345 saying 'Engineering has identified the root cause and is deploying a fix' and change status to identified
Schedule Maintenance
@Instatus schedule maintenance titled 'Database Migration' for tomorrow 2am to 4am UTC, mark the database component as under maintenance, and notify subscribers 24 hours before start
Mark Service Degraded
@Instatus set the CDN component status to degraded performance with the message 'Elevated response times in US-East region'
Close Resolved Incident
@Instatus add a final update to incident #12345 saying 'All systems restored, monitoring for stability' and resolve the incident, setting all components back to operational
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@Instatus what's the current status of our API and database components on the production status page?
Here's the current state of those components: **API Gateway** (id: comp_abc123) - Status: Operational - Show uptime: Yes - Current uptime: 99.97% - Last updated: 2 hours ago **Database Cluster** (id: comp_def456) - Status: Degraded Performance - Show uptime: Yes - Current uptime: 99.89% - Last updated: 15 minutes ago The database component is currently marked degraded. This status is publicly visible to all status page subscribers.
This read-only query uses Get Component to fetch real-time health data. Requires API key with read access to the target status page. The response reflects whatever state you've manually or programmatically set in Instatus — it doesn't monitor your infrastructure directly.
@Instatus create an incident titled 'Elevated API Error Rates' affecting our API Gateway component, set severity to major, and notify subscribers.
Incident created and published: **Elevated API Error Rates** (id: inc_xyz789) - Status: Investigating - Severity: Major outage - Affected components: API Gateway (set to Major Outage) - Notifications sent: Yes (page subscribers + API Gateway subscribers) - Public URL: https://status.yourcompany.com/incidents/inc_xyz789 The incident is now live on your status page. Subscribers received email/SMS/webhook notifications based on their preferences. You can add updates via Add Incident Update to change the status to Identified, Monitoring, or Resolved.
This uses Create Incident with notify=true, which immediately sends external notifications. Be cautious: there's no undo for sent notifications. The affected component's status changes publicly the moment the incident is created. Requires API key with write permissions.
@Instatus review all open incidents from the last 48 hours and draft a summary email explaining what happened and current resolution status.
I found 2 open incidents in the last 48 hours: **Draft Summary:** Subject: Status Update – Recent Service Disruptions Team, We experienced two service issues over the past two days: 1. **Elevated API Error Rates** (Major, ongoing since Jan 15 3:42 PM) - Currently: Monitoring - Impact: API Gateway returned 5xx errors for ~12 minutes - Resolution: Traffic rerouted to backup cluster; monitoring for stability 2. **Database Replication Lag** (Minor, Jan 14 11:20 AM – resolved) - Duration: 3 hours 15 minutes - Impact: Read replicas lagged primary by up to 45 seconds - Resolution: Replication caught up after index optimization We'll post final retrospectives once the API incident is fully resolved. This summary is based on your public incident timeline and update history.
This synthesis example pairs Get Incident queries with AI reasoning to produce stakeholder communication. The AI interprets your incident updates but can't verify technical accuracy — review the draft before sending. Useful for weekly status reports or post-incident summaries when you have multiple overlapping events.
Use-case deep-dives
When Instatus beats Slack for customer-facing downtime updates
A 6-person SaaS team running a B2B dashboard hits a database failover at 2am. The on-call engineer needs to tell 400 customers what's happening without waking the whole team or copy-pasting into three channels. Instatus wins here because Create Incident and Add Incident Update push structured status changes to a public page and trigger subscriber emails in one call—no manual Slack-to-Twitter-to-email choreography. The MCP's notify flag controls whether updates ping subscribers, so you can draft internally before broadcasting. If your customer base is under 50 and you already have a #incidents Slack channel they watch, skip the overhead. Above that threshold, the status page becomes your single source of truth and this MCP is the fastest way to script it from an AI workspace.
Automate maintenance comms when you deploy weekly
A 3-person DevOps team ships database migrations every Tuesday at 6am UTC and needs to warn 12 enterprise customers 48 hours ahead. Create Maintenance and Add Maintenance Update let you template the full lifecycle—scheduled announcement, start confirmation, completion note—and the MCP's notify_start and notify_end flags automate the customer emails without manual intervention. This works when your maintenance cadence is predictable and your status page is already the customer's go-to for uptime. If you deploy ad-hoc or your customers don't check the status page, the automation overhead outweighs the benefit and you're better off with calendar invites. For teams running regular maintenance windows with 10+ external stakeholders, this MCP turns a 15-minute copy-paste ritual into a 2-minute scripted update.
When Get Component makes sense for status-driven runbooks
A 10-person platform team runs 8 microservices behind a status page and wants to pull current component health into their incident response runbook. Get Component returns the live degradation state so an AI agent can decide whether to escalate based on what's already public. This is useful when your runbook logic branches on "is the API already marked degraded?" and you want one source of truth. The trade-off: if your monitoring stack (Datadog, PagerDuty) already feeds Instatus via webhook, querying the MCP adds a round-trip that your alerting tool skips. Use this when you're building status-aware automation in Switchy and the 15-tool surface covers your incident and maintenance workflows end-to-end. Skip it if you only update the status page manually twice a quarter.
Frequently asked
What does the Instatus MCP let me do in Switchy?
It lets AI agents create and update incidents, maintenances, and components on your Instatus status page. Agents can post lifecycle updates, change component health states, and trigger subscriber notifications—all from natural language prompts. You don't need to context-switch to the Instatus dashboard when an outage happens.
Do I need admin access to connect Instatus?
You need an Instatus API key with write permissions to your status page. That typically means owner or admin access in Instatus. The key lives in Switchy's credential store; team members using the MCP don't see it. If your Instatus account restricts API keys to specific pages, make sure the key covers the page you want to update.
Can the MCP send notifications to my status page subscribers?
Yes. When you create or update an incident or maintenance, you can set notify=true to send emails and webhooks to subscribers. The MCP exposes this as a parameter, so you control whether each action triggers external notifications. Use it carefully—agents can spam your subscriber list if you're not explicit in your prompts.
How is this different from updating Instatus manually or via API?
It's the same underlying API, but wrapped in natural language. Instead of writing curl commands or remembering field names, you tell an agent "mark the API component degraded and post an incident update." The MCP handles JSON serialization and endpoint routing. You trade precision for speed—fine for routine updates, less so for complex multi-step workflows.
Who on my team should connect the Instatus MCP?
Whoever owns incident comms or on-call rotations. They'll use it to draft status updates during outages without leaving Switchy. Everyone else can read the status page like normal. The MCP doesn't count against Instatus seat limits—it's just an API client—but it does count as one connected integration in your Switchy plan.