Skip to main content

Getting Started

This guide is for teams setting up StatiBeat for the first time.

Use it when you want the shortest route from zero to a working page, without having to think about API tokens, Terraform, or MCP yet.

If your manual workflow is already in good shape and you want to automate more, jump to Automation and Integrations.

Before you start

You need an admin login and a workspace with a status page. If your trial is still provisioning, watch the walkthrough first; the exact menu names below are the ones used in the demo.

Watch the getting started demo​

If your trial is still provisioning, this four-minute walkthrough shows the first setup flow: sign in, create hierarchy levels and items, publish an incident, compare the Modern and Classic public layouts, and resolve the incident.

Text alternative

The walkthrough signs in, opens Service Model → Hierarchy Levels, creates Service, Region, and Component levels, then opens Service Model → Hierarchy Items to create Payments, EU West, Checkout API, and Billing Portal. It then opens Overview & Operations → Incidents, publishes a degraded incident for Checkout API, checks the public page in the Modern and Classic layouts, and resolves the incident.

The shortest useful rollout​

1. Define the services your customers care about​

Start with the things customers actually understand:

  • products
  • regions
  • services
  • major components

This gives your status page a structure customers can follow when incidents happen.

2. Set up your public status page​

Your status page should make it easy for users to answer three questions:

  1. Is something wrong?
  2. What is affected?
  3. Is the team working on it?

StatiBeat is designed to make those answers visible quickly.

What success looks like

When you open the public page, a reader should be able to identify the overall status, the affected area, and the latest update without needing to know your internal architecture.

3. Prepare incident and maintenance templates​

Templates help your team move faster when the pressure is on. Prepare common update patterns ahead of time so nobody has to write from scratch during a stressful incident.

4. Decide who can publish updates​

Before your first serious incident, make sure the right people have access to publish updates, plan maintenance, and manage service structure.

If you plan to automate those workflows later, read the API Quickstart and API Tokens before you build scripts or bots.

5. Test the workflow​

Run through a mock incident:

  • mark an affected service
  • post a customer-facing update
  • resolve the incident
  • review how the timeline reads from a customer perspective

That gives your team confidence before the real thing.

Follow the demo path in the app​

Use this exact path if you want to reproduce the walkthrough manually:

  1. Open Service Model → Hierarchy Levels and select Add Level. Create the levels Service, Region, and Component, in that order.
  2. Open Service Model → Hierarchy Items and select Add Item. Create Payments as the top-level service.
  3. Add EU West under Payments, then add Checkout API and Billing Portal under EU West.
  4. Open Overview & Operations → Incidents and select Create Incident.
  5. Choose Checkout API, enter a customer-facing title and update, choose a degraded status, and select Create.
  6. Open the public status page from the profile menu. Confirm that Checkout API is degraded while Billing Portal remains operational.
  7. Return to Incidents, select Resolve, add a final update, and confirm the public page shows the resolved state.

If a menu or field is not visible, your role, plan, or page configuration may be different. Use Application Overview to identify whether you need organization admin or page admin access.

6. Add proactive monitoring only after the manual path works​

If you want StatiBeat to help spot issues before customers report them, add one or two Beats for your most important customer-facing paths first.

Good early candidates are:

  • a public homepage or status-page HTTP check
  • a core API health endpoint
  • an SSL certificate check for a customer-facing hostname

Start small, confirm the thresholds make sense, and decide whether warning or critical stages should stay as reviewable drafts or post automatically.

You are ready to go live when​

  • the public page has a small, understandable hierarchy
  • one test incident has a clear title, affected component, and final update
  • the team can tell who publishes incidents, schedules maintenance, and manages access
  • the public page is readable on both desktop and mobile

Keep the first rollout simple​

  • Start with the public page, hierarchy, and incident flow before you add integrations.
  • Make the customer-facing naming stable before you automate anything against it.
  • Give the team one mock incident run before you introduce Slack, Beats, Terraform, or Hosted MCP.

When to add the deeper setup​

Add these once the core operating path feels predictable:

Keep going with the basics​

  1. Read First-Run Setup.
  2. Read Admin Quickstart.
  3. Read Designing Your Hierarchy.
  4. Read Public Status Pages.
  5. Read Incidents and Maintenance.

When you are ready to go deeper​

  1. Read Automation and Integrations.
  2. Read API Quickstart or API Reference.
  3. Read Terraform Workspace and Export or Terraform Provider Overview.
  4. Read Hosted MCP.
  5. Read Beats if you want synthetic checks and automated drafts.