> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aciona.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Services

> What is monitored, who answers for it, and how an alert finds the right service.

A service represents something that is monitored and has an owner: `payments-api`, `checkout`, `auth`, `erp-integration`, `messaging-platform`.

It exists for one practical reason: to turn a technical alert into human responsibility.

## Create a service

Under **Services**, owners and admins define:

| Field                | What it is for                                                                      |
| -------------------- | ----------------------------------------------------------------------------------- |
| **Name**             | Identifies the service and is used for routing. Make it match what your tool sends. |
| **Responsible team** | Decides who gets paged.                                                             |
| **Default severity** | Criticality context when the alert has no recognizable severity.                    |

## How an alert finds its service

aciona.me resolves the service in this order:

<Steps>
  <Step title="Default service on the alert source">
    If the source has a fixed service configured, it is used. Handy when an entire tool monitors a single service.
  </Step>

  <Step title="Service hint in the alert">
    Each source type takes the hint from a different place:

    | Source          | Where the hint comes from                            |
    | --------------- | ---------------------------------------------------- |
    | Generic webhook | `service` field or `service` label                   |
    | Prometheus      | labels `service` → `job` → `instance`                |
    | Grafana         | alert labels                                         |
    | Datadog         | `service:` tag → scope → hostname → metric           |
    | New Relic       | affected-service tag → entity → condition → policy   |
    | Zabbix          | host name                                            |
    | CloudWatch      | alarm dimension for the namespace, or the alarm name |
  </Step>

  <Step title="Auto-registration">
    If the hint points at a service that does not exist yet, aciona.me can register it automatically so the alert is not lost.
  </Step>
</Steps>

<Warning>
  Auto-registered services start with **no responsible team**. Review them regularly and link them to the right team — until then, their incidents have nobody on call.
</Warning>

<Note>
  Auto-registered services are not blocked by plan limits. That is deliberate: aciona.me never fails to create an incident because of a resource limit.
</Note>

## Service severity

The service's default severity is the criticality context used when an alert arrives without a severity aciona.me recognizes. When the alert carries its own severity, that wins.

The possible severities are `critical`, `high`, `warning` and `info`. See how each tool's values are mapped in [Severities](/en/reference/severities).

## Deleting a service

A service with open incidents cannot be deleted. Resolve or close those incidents first.

<Columns cols={2}>
  <Card title="Teams" icon="users" horizontal href="/en/teams/overview" />

  <Card title="Alert sources" icon="webhook" horizontal href="/en/alert-sources/overview" />
</Columns>