> For the complete documentation index, see [llms.txt](https://docs.statuspal.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.statuspal.io/next/incident-management/configure-incident-management-services.md).
# 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.
{% hint style="info" %}
**These are not your status page services.** The services on this page belong to Incident Management and are only visible to your team. The services your customers see live on each status page, and incidents about them are published as incident notices. See [Incident, Maintenance & Info Notices](/next/status-pages/incident-maintenance-and-info-notices.md). The two are linked only through the status page mapping described below.
{% endhint %}
## 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](/next/incident-management/runbooks.md) 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](/next/incident-management/manage-incidents.md).
{% hint style="warning" %}
**Mappings can change while an incident is open.** If you remove a component from the mapping mid-incident, any notice already affecting it is still resolved when the incident is, so nothing gets stuck showing an outage. Components you add mid-incident on a page that already has the notice are picked up by the next published update.
{% endhint %}
