Statuspage

Manage Atlassian Statuspage from your flows. Agents open and advance incidents, publish scheduled maintenance windows, flip component statuses as health checks change, and add email, SMS, or webhook subscribers.

14 actions API key available

Statuspage website ↗ Platform Documentation ↗ Capability data verified 2026-07-27

A monitoring alert fires for the API service

List Unresolved Incidents confirms no incident is already open for the same components

Update Component flips the API component to Partial Outage so the page reflects reality immediately

Agent drafts the incident from the alert context: name, impact, affected components, first update text

The draft posts to the incident channel for review alongside the alert evidence

The incident owner approves the wording; only then does Create Incident publish the first update to subscribers

What This Integration Enables

A status page is a promise you make to customers, and Statuspage enforces the weight of it: every incident created and every update posted goes out to subscribers over email, SMS, and webhooks. There is no unsend. FlowRunner agents are built around that asymmetry. The mechanical work runs autonomously: flipping component statuses as health checks change, checking for duplicate incidents, advancing an incident through investigating, identified, monitoring, and resolved as the response progresses, and keeping subscriber lists current. The public words, the part that reaches customers, pass through a person first. Agents also manage the page itself: creating and organizing components as services ship, publishing scheduled maintenance windows so planned work never masquerades as an outage, and feeding incident history into audit and reporting pipelines through List Incidents and Get Incident.

Without FlowRunner

Page lags reality Customers see all-operational while support tickets pile up

Wordsmithing during the fire The engineer debugging the outage is also drafting the public copy

Duplicate incidents Two responders open two incidents for the same outage

With FlowRunner

Components flip with the checks Update Component reflects degraded status the moment it is verified

Drafts arrive written The incident text is prepared; a human approves it and it publishes

One incident per outage List Unresolved Incidents is checked before anything opens

Use Case Scenarios

Incident Lifecycle From Alert to Resolved

A [PagerDuty](/integrations/pagerduty) incident triggers the flow. The agent verifies against List Unresolved Incidents, sets the affected components, and stages the incident draft for approval. Once published with Create Incident, the agent keeps the page current: each status change in the response is mirrored with Update Incident, moving through identified and monitoring to resolved, each update approved by the incident owner before it goes to subscribers. The timeline customers see matches the response as it happened.

Component Health That Mirrors Monitoring

When a [Datadog](/integrations/datadog) monitor degrades, the agent runs Update Component to flip the matching component to Degraded Performance or Major Outage, and back to Operational when the monitor recovers. Component flips are page-state changes rather than composed messages, so this loop runs autonomously, with each change posted to [Slack](/integrations/slack) for visibility. The page stops being the last system to know.

Maintenance Windows Published Ahead of the Work

A deployment plan includes customer-visible downtime. The agent drafts the maintenance from the change ticket, lists the affected components, and schedules it after the owner approves the wording and window. List Scheduled Maintenances feeds the weekly ops review so planned work is visible before it happens, and subscribers hear about downtime from the schedule, not from the outage.

Human-in-Loop Highlight

Create Incident publishes its first update to every subscriber the moment it runs, by email, SMS, and webhook, and nothing recalls a notification once sent. So the agent's draft always stops at a person: "Draft incident for the API component: 'Investigating elevated error rates on the API. Checkout may fail intermittently.' Impact: partial outage. Publishing notifies all subscribers. Publish as written, edit, or hold?" The incident owner owns the words that reach customers; the agent owns everything around them. The same [human-in-the-loop](/concepts/human-in-the-loop/) rule protects incident history: closing an incident means Update Incident to Resolved, never Delete Incident, which permanently erases the incident and its timeline from the public record.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via email

Human decides

Agent resumes with decision

Agent Capabilities

14 actions

Incidents

List Incidents Retrieves all incidents, open and resolved, newest first, with search and pagination. The feed for audit and reporting pipelines.
List Unresolved Incidents Retrieves the currently active incidents: investigating, identified, or monitoring. The duplicate check that runs before anything opens.
Get Incident Retrieves one incident in full, including status, impact, affected components, and the chronological update timeline shown on the page.
Create Incident Creates a realtime incident and publishes its first update to subscribers, setting affected components and impact. Runs only after a human approves the wording.
Update Incident Posts a new update to an incident, advancing its status and notifying subscribers. How an incident moves through investigating, identified, monitoring, and resolved.
Delete Incident Permanently deletes an incident and its updates from the history. Cannot be undone; resolution, not deletion, is how incidents close.

Scheduled Maintenance

List Scheduled Maintenances Retrieves maintenance events that are scheduled, in progress, verifying, or completed. Feeds ops reviews and prevents planned work from reading as an outage.

Components

List Components Retrieves the components and component groups on the page with their current statuses. The map of what the page says is healthy.
Get Component Retrieves one component's status, description, group membership, and display settings.
Create Component Adds a component for a new service, with group assignment, initial status, and visibility settings.
Update Component Changes a component's operational status (operational, degraded performance, partial outage, major outage, under maintenance), reflected immediately on the page. The workhorse of monitor-driven health mirroring.
Delete Component Permanently removes a component from the page and from incidents' affected-component lists. Cannot be undone, so it is confirmed before running.

Subscribers

List Subscribers Retrieves the page's email, SMS, and webhook subscribers, with the components each is scoped to.
Create Subscriber Adds a subscriber by email, phone, or webhook endpoint, optionally scoped to specific components, so customers hear about exactly the systems they depend on.

Frequently Asked Questions

What can FlowRunner do with Statuspage?

FlowRunner agents can run List Incidents, List Unresolved Incidents, and List Scheduled Maintenances in Statuspage, plus 11 more actions.

Does connecting Statuspage to FlowRunner require OAuth?

No. Statuspage connects to FlowRunner with an API key, no OAuth flow required.

Can Statuspage trigger a FlowRunner workflow automatically?

Statuspage doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Statuspage

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us