> ## 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.

# Create a service

> Services represent what is monitored and determine which team gets paged.

The service is the bridge between a technical alert and human responsibility: the alert points at a service, the service points at a team, the team has a schedule, and the schedule has someone on call.

## Creating one

<Steps>
  <Step title="Open Services and create a new one">
    Use a name your monitoring tool can also report: `payments-api`, `checkout`, `auth`, `erp-integration`.
  </Step>

  <Step title="Pick the responsible team">
    This link decides who gets paged.
  </Step>

  <Step title="Set the default severity">
    Used as context when an alert arrives without a recognizable severity.
  </Step>
</Steps>

<Tip>
  Make the service name match what your tool sends — the `service` label in Prometheus/Grafana, the `service:` tag in Datadog, the alarm dimension in CloudWatch. Routing then works with no extra configuration.
</Tip>

## How an alert finds its service

aciona.me tries, in order:

1. The **default service** configured on the alert source, when one exists.
2. The **service hint** carried by the alert (`service` field, `service` label, `service:` tag, alarm dimension — it varies by tool).

If the hint points at a service that does not exist in the organization yet, it can be **registered automatically**, so the alert is never lost. Auto-registered services do not count against plan limits, but they start with no responsible team — review them and link them to the right team.

<Warning>
  A service without a responsible team produces incidents with nobody on call. See [No on-call user found](/en/troubleshooting/no-on-call-user).
</Warning>

<Card title="Next: set up the schedule" icon="calendar-clock" horizontal href="/en/getting-started/create-schedule" />