Browse the docs

How Status Bee is organised

Organisations, workspaces, pages, components, monitors and subscribers, and how they relate.

On this page
  1. Organisation
  2. Workspace
  3. Status page
  4. Component
  5. Incident
  6. Maintenance window
  7. Monitor
  8. Subscriber
  9. Members and roles
  10. How they fit together

Six nouns cover everything in the product. Once they are clear, every screen and every API endpoint makes sense.

Organisation

The account that pays. It owns the plan, the billing details, the API keys and the team. A person can belong to several organisations, for example their own and a client's, and switches between them from the sidebar.

Workspace

Where the work happens. A workspace holds status pages, monitors, incidents, maintenance windows, subscribers, message templates and outbound webhooks, and nothing in it is visible from another workspace. Every organisation has one to start with. Agencies create one per client; a company with several products might create one per product. Plans set how many you can have.

Everything operational is scoped to a workspace. If two things should never see each other, put them in different workspaces.

Status page

A public web page at {slug}.statusbee.co or your own domain, showing the current state of a set of components, open incidents, scheduled maintenance and a history of both. A workspace can have several pages, for example one per audience. Pages are published once and then stay up; they are served from a prebuilt snapshot, so they load fast and keep working even when the dashboard does not.

Component

One row on a status page: “Checkout”, “API”, “Email delivery”. Each has a status from the fixed vocabulary Operational, Degraded, Partial outage, Outage or Maintenance, an uptime history, and optionally a monitor that drives it. Components can be grouped for readability.

Incident

Something that went wrong, told to customers over time. An incident has a title, an impact (none, minor, major, critical), the components it affects, and a timeline of updates that move it through Investigating, Identified, Monitoring and Resolved. Each update can notify subscribers. Incidents can be drafted privately and published later, and once published they are never deleted, only resolved.

Maintenance window

Planned downtime, announced in advance. It has a start and an end, the components it touches, reminder offsets, and a status: scheduled, in progress, completed or cancelled. Affected components show Maintenance while it runs instead of an outage.

Monitor

A check that runs on a schedule from our probes: HTTP(S), TCP, ping, DNS, SSL expiry or a heartbeat your own job pings. A monitor is up or down based on consecutive results, and its rules decide what a change does to components and incidents.

Subscriber

A person or system that asked to hear about a page's incidents and maintenance, on a channel they chose: email, SMS, Slack, Discord, Telegram, Teams or a webhook URL. Subscribers belong to a page and can follow only some of its components. There is no limit on how many a page has, on any plan.

Members and roles

People in your organisation. Organisation-level roles (owner, admin, billing) apply everywhere; workspace-level roles (admin, incident manager, maintenance manager, editor, viewer) apply to one workspace. Roles are sets of permissions, and the dashboard hides what a member cannot do. See Team members and roles.

How they fit together

ThisBelongs toCan have many
Organisationitselfworkspaces, members, API keys
Workspacean organisationpages, monitors, incidents, maintenance windows, templates, webhooks
Status pagea workspacecomponents, groups, subscribers, custom domains
Componenta pageone linked monitor, many incidents over time
Incident, maintenance windowa page (and its workspace)updates, affected components
Monitora workspacerules pointing at components on any page in the workspace