Skip to main content

Automation, Integrations, and API

StatiBeat includes several operator-facing automation surfaces: API tokens, Slack, Beats, Hosted MCP, and the page-scoped MCP server.

API token management in the live demo

Slack settings in the live demo

API tokens

API tokens are the credential layer for programmatic access to the StatusPage API.

Use them when you need:

  • scripts
  • internal tools
  • CI/CD automation
  • Terraform-adjacent workflows
  • external integrations

The key decisions are:

  • read, write, or admin permission
  • the page-scoped RBAC role
  • expiration policy
  • whether the token is intended for Terraform-managed workflows

Slack integration

The Slack workspace is where you connect StatiBeat to operational communication.

Current Slack capabilities include:

  • OAuth-based app connection
  • channel-link policies
  • global announcements
  • reminders
  • per-channel overrides
  • workflow confirmation modes for Slack-initiated actions

Slack is most useful when incident coordination already happens in channels and you want status communication to stay close to the work.

MCP integration choices

Hosted MCP is the product path for remote AI clients. It uses StatiBeat OAuth, page discovery, user consent, approved-client management, revoke controls, recent activity, and a deliberately narrow write surface for incidents and maintenance.

The page MCP server is the trusted automation path for stdio MCP clients that are configured with a scoped API token. It exposes the broader page operational surface, including incident lifecycle actions, maintenance lifecycle actions, manual Beat runs, and pending Beat action approval or rejection. Use MCP Reference when you need the exact current resource, prompt, and tool list.

Beats

Beats are StatiBeat's synthetic monitoring workspace.

They can:

  • monitor customer-facing paths
  • capture evidence
  • raise alerts
  • create reviewable drafts
  • auto-post incidents or recoveries when configured to do so

Beats can also be grouped under optional Beat Groups.

  • standalone Beats keep their original incident and messaging ownership
  • grouped Beats still evaluate their own thresholds and evidence
  • the Beat Group can own channel routing, incident lifecycle, and customer-facing message templates for the whole grouped surface

Beats are strongest when they are connected to the same hierarchy and communication model your customers already see.

External Beat Triggers extend Beats to external signals. Admins can ingest generic webhook JSON, select fields from a historical inbox event, preview the rule against older events, and turn matching events into Beat warning, critical, or recovery transitions. Start these triggers in draft/review mode so Slack and the admin UI can review customer-facing drafts before anything posts publicly.

If you are adding automation for the first time:

  1. get the manual public workflow right
  2. create the minimum viable API token set
  3. connect Slack
  4. configure AI only if assisted drafting is genuinely useful
  5. connect Hosted MCP only after admins understand the OAuth scopes and recent activity view
  6. use the page MCP server only for trusted API-token automation that needs broader operational tools
  7. add one or two Beats before scaling monitoring broadly
  8. add External Beat Triggers only after preview shows stable firing and recovery behavior

That sequence keeps the automation grounded in a communication model your team already trusts.