Instatus

Instatus

Status page platform for communicating service health to customers. Manage public status pages, track incidents and scheduled maintenances, and monitor component-level uptime.

Entity Hierarchy

Everything is scoped to a status page (identified by page_id). Enumerate status pages first.

Account Level (no page_id needed)

• User — current authenticated user's account info.
• Public Data — read public status page data by page subdomain url (e.g., instatus) without managing credentials for that read surface.

Page Level (requires page_id)

• Status Pages — the top-level entity. Each page has a subdomain, custom domain, and display settings. Enumerate pages to discover page_id.
• Components — individual services/systems shown on the page (e.g., "API", "Dashboard", "CDN"). Each has a status: operational, degraded, partial outage, major outage. Open a component by component_id for full uptime data and monitoring config.
• Incidents — unplanned disruptions. Each incident has a status (investigating, identified, monitoring, resolved) and a timeline of updates. Open an incident by incident_id for full details including all timeline updates and affected components. Scoped by page_id.
• Maintenances — scheduled downtime windows. Similar to incidents with status lifecycle and timeline updates. Scoped by page_id.
• Metrics — uptime percentages or custom metrics displayed on the page. Scoped by page_id.
• Subscribers — people subscribed to status notifications (email, webhook, Slack). Scoped by page_id.
• Team — team members with management access to the page. Scoped by page_id.
• Templates — reusable incident/maintenance templates for common scenarios. Scoped by page_id.

Update Level (requires page_id + parent object ID + update ID)

• Incident Updates — individual timeline entries on an incident. Requires page_id, updates_object_id (the incident ID), and incident_update_id.
• Maintenance Updates — individual timeline entries on a maintenance. Requires page_id, updates_object_id (the maintenance ID), and maintenance_update_id.

Workflows

• Status overview: enumerate status pages → enumerate components for a page → open one component for uptime data and monitoring details.
• Incident investigation: enumerate status pages → enumerate incidents (with page_id) → open one incident for the full timeline → pull individual updates for detailed entries.
• Maintenance review: enumerate status pages → enumerate maintenances → read maintenance updates for scheduled work history.
• Subscriber management: enumerate status pages → enumerate subscribers to see who's receiving notifications.
• Public status check: load public page data using the page’s subdomain url.

Gotchas

• page_id is required for almost everything: enumerate status pages first. It's a prerequisite for incidents, maintenances, components, metrics, subscribers, team, and templates.
• Updates are three levels deep: page_id → parent object ID (incident or maintenance) → update ID. Enumerate incidents or maintenances first to get the parent ID, then open individual updates.
• Public data uses url (subdomain name), not page_id.