Configure your services
Define the services your team responds to, set each one's default severity, and map them to status page components so incidents can publish updates.
Incident management services are the list of components your team is on the hook for. Every incident you declare is attached to one of them, and that choice decides which runbooks fire and what the default severity for the incident will be.
What incident management services are for
Think of a service as a unit of ownership: the API, the web app, the background workers, the data pipeline. It should cover everything your team might be paged for, including internal systems your customers never hear about. That is the point of keeping them separate from the status page: you can track an incident on an internal service without publishing anything.
Each service carries a live status that incidents update as they progress, so the Incident Management → Services list doubles as an internal health board. Services also drive automation. When you declare an incident, the service you pick decides which runbooks match, pre-fills the severity, and determines whether the incident can be published to a status page.
Members and admins can create and edit services. Only admins can delete one, and you always need at least one service. Deleting a service also deletes every incident declared against it, along with their updates, so the confirmation dialog tells you how many incidents that is.
Service form fields
Go to Incident Management → Services and click New service.
Name: how the service appears in incident forms, runbook rules, Slack messages, and the activity timeline. Use the name your team already uses in conversation.
Service Status: the service's current health, one of Operational, Degraded, Partial outage, or Unavailable. You rarely set this by hand. Declaring or updating an incident with a service status moves the service to match, and resolving the incident returns it to Operational. Set it here only to correct the starting state or to record a problem outside an incident.
Default incident severity: the severity pre-selected when someone declares an incident for this service. Choose None to leave the field blank and force a conscious choice, or pick Minor, Major, or Critical. The person declaring can still change it. Severity is what runbook matching rules and the published impact key off, so a sensible default here saves a decision during an incident.
Status page mapping
The Status Page Mapping section links this service to the components on your status pages. It only appears when the Status Pages module is enabled for your workspace.
Click Add Mapping, choose a Status Page, then pick one or more components under Service. Components are listed as "Service → Container" when the service sits in a container, for example "API → US", so a service that runs in several regions can be mapped region by region. A component without a container is listed by name alone. Each status page gets one row, and you can add as many rows as you have pages. The trash icon removes a row, and only pages you have access to are offered. Mappings to pages you cannot access are kept but shown locked.
Mapping is optional. A service with no mappings is valid. Its incidents stay internal.
Once mapped, incidents on this service can be published. When you declare or update an incident with Publish to Status Page switched on, StatusPal Next creates an incident notice on every mapped page, marks the mapped components with an impact that matches the incident's severity, and notifies subscribers if you ask it to. Later updates are appended to those notices, and resolving the incident resolves them and returns the components to Operational. See Manage incidents.
Last updated