Instatus API

Name: Instatus API API
Brand: Instatus API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsMonitoring Observabilitybearer14 EndpointsREST

For Agents

Manage Instatus status pages, components, and incidents — create pages, update component health, and post incident updates programmatically.

Quickstart

Get started with Instatus API in minutes using your preferred integration method.

# Add to your MCP client config (Claude Desktop, Cursor, Windsurf)
{
  "jentic": {
    "url": "https://api.jentic.com/mcp",
    "auth": "oauth"
  }
}

# Then ask your agent:
"post an Instatus incident"

# → Jentic returns the GET /events tool with parameter schema, agent executes.

Capabilities

What an agent can do with Instatus API API.

List and update status pages via /v2/pages and /v2/{page_id}

Read and update individual components on a page via /v2/{page_id}/components/{component_id}

Create new components on a page via POST /v1/{page_id}/components

Post and update incidents tied to a page so subscribers see real-time progress

GET STARTED

Start building with Instatus API API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for Instatus API, keeping it validated and agent-ready.

Jentic publishes the only available OpenAPI specification for Instatus API, keeping it validated and agent-ready. The Instatus API lets engineering teams manage public and private status pages — pages, components, and incidents — programmatically across 14 endpoints. Most operations live under /v2, with a few /v1 create endpoints retained for compatibility, so an automation can create a page, attach service components, and post incidents from CI/CD or monitoring tooling. Authentication uses a bearer token issued from the Instatus dashboard.

Use Cases

Patterns agents use Instatus API API for, with concrete tasks.

★ Auto-Post Incidents from Monitoring

When the monitoring system fires a critical alert, post a corresponding incident on Instatus so subscribers see the outage immediately. The integration uses the page id and component id from a config file, posts an incident with affected component and impact level, and follows up with status updates as the incident progresses.

When alert fires, POST a new incident on the configured page with the impacted component id and an initial 'investigating' status.

Component Health Sync from Health Checks

Mirror component health from an internal monitor into Instatus by calling PUT /v2/{page_id}/components/{component_id} whenever a check transitions between operational, degraded, and major outage. The status page reflects current state without an operator having to flip the component manually, and the small endpoint count makes this integration tractable in a few hours.

On health-check transition, PUT /v2/{page_id}/components/{component_id} with the new component status.

Multi-Page Provisioning for New Services

When a new internal service launches, create a dedicated Instatus page with POST /v1/pages, attach the relevant components via POST /v1/{page_id}/components, and store the resulting ids in service metadata. The provisioning step makes a status page available the day a service goes live without manual setup.

POST /v1/pages with the service name, then POST /v1/{page_id}/components for each tracked component.

AI Agent Incident Operator via Jentic

An on-call AI agent given access to Instatus through Jentic can open and update incidents in plain language. Jentic exposes each Instatus operation by intent and isolates the bearer token in its vault, so the agent posts updates without ever holding the credential.

Through Jentic, call instatus_create_incident with the page id, affected component id, and an initial 'investigating' message; follow up with instatus_update_incident as new information arrives.

Key Endpoints

14 endpoints — jentic publishes the only available openapi specification for instatus api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/v2/pages

List status pages

POST

/v1/pages

Create a status page

PUT

/v2/{page_id}

Update a status page

DELETE

/v2/{page_id}

Delete a status page

GET

/v2/{page_id}/components

List components on a page

PUT

/v2/{page_id}/components/{component_id}

Update a component status

GET

/v2/pages

List status pages

POST

/v1/pages

Create a status page

PUT

/v2/{page_id}

Update a status page

DELETE

/v2/{page_id}

Delete a status page

GET

/v2/{page_id}/components

List components on a page

PUT

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Instatus bearer tokens are stored encrypted in the Jentic vault and injected into the Authorization header at execution time. Agents never hold the raw token.

Intent-based discovery

Agents search Jentic by intent (for example 'post an Instatus incident' or 'update a component status') and Jentic returns the matching operation with its input schema.

Time to first call

Direct integration: about a day to wire bearer auth, page and component CRUD, and incident posting. Through Jentic: under 30 minutes — search, load, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Alternative

Statuspage API

Atlassian Statuspage offers status pages with deeper enterprise governance.

Choose Statuspage when the team already runs the Atlassian stack and needs Jira-aligned incident workflows.

Alternative

Better Stack API

Better Stack combines uptime monitoring with status pages in a single product.

Choose Better Stack when you want monitoring and status pages from one vendor instead of integrating two.

Complementary

UptimeRobot API

UptimeRobot supplies the uptime monitor data that triggers Instatus incident posts.

Pair with Instatus when monitor checks live in UptimeRobot and incident communication lives in Instatus.

FAQs

Specific to using Instatus API API through Jentic.

Why is there no official OpenAPI spec for Instatus API?

Instatus does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Instatus API via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.

What authentication does the Instatus API use?

The Instatus API uses bearer authentication. You issue a token from the Instatus dashboard and send it as Authorization: Bearer <token>. Through Jentic, the bearer token is held in the encrypted Jentic vault and injected into the request at execution time.

Can I post incidents and update components with the API?

Yes. The spec includes endpoints under /v2/{page_id}/components/{component_id} for component status changes, and incident endpoints for posting and updating incidents. An automation can drive the full incident lifecycle from monitoring alerts.

What are the rate limits for the Instatus API?

The OpenAPI specification does not encode explicit rate limits. Status-page operations are typically low-frequency, so design integrations around event-driven calls rather than polling, and back off on 429 responses if they occur during incident bursts.

How do I open an incident through Jentic?

Run pip install jentic, then have the agent issue the search-load-execute flow with the query 'post an Instatus incident'. Jentic returns the matching operation; the agent supplies the page id, affected component id, status, and message, and gets back the created incident id.

Are page creation endpoints on /v1 or /v2?

Creation of pages and components in this spec sits on /v1 (POST /v1/pages and POST /v1/{page_id}/components), while reads, updates, and deletes use /v2. Use both prefixes side by side based on the operation.