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

# How aciona.me works

> The full path of an alert: ingestion, routing, incident, notification, escalation and resolution.

aciona.me has a single core flow. Understanding it is enough to configure the whole product — and to diagnose almost any operational problem.

## The flow in one line

**Alert received → service identified → responsible team → person on call → incident created → person notified → acknowledgement → escalation (if nobody responds) → resolution.**

```mermaid theme={null}
flowchart LR
  A["Monitoring tool"] -->|"webhook + token"| B["Alert source"]
  B --> C["Normalized alert"]
  C --> D["Affected service"]
  D --> E["Responsible team"]
  E --> F["Person on call"]
  F --> G["Incident"]
  G --> H["Notifications"]
  H --> I["ACK / take ownership"]
  I --> J["Resolution"]
  G -.->|"no ACK in time"| K["Escalation"]
  K --> H
```

## 1. Ingestion

Each monitoring tool points at its own **alert source** inside aciona.me. Every source has a unique URL and token:

```bash theme={null}
POST https://ingress.aciona.me/webhooks/<alertSourceId>
X-Aciona-Token: <sourceToken>
```

The source determines which organization owns the alert and how the payload is interpreted — aciona.me never trusts an organization identifier coming from the request body.

aciona.me replies `202 Accepted` as soon as the alert is persisted. Processing happens right after, asynchronously, so your monitoring tool never waits.

<Info>
  The original payload is always stored alongside the alert, for auditing and diagnosis. See [Plans and limits](/en/reference/plans-and-limits).
</Info>

## 2. Normalization

Each source type has its own translator that turns the tool's payload into a shared internal shape:

| Field         | Meaning                                            |
| ------------- | -------------------------------------------------- |
| `title`       | Human-readable alert title                         |
| `description` | Detail or reason for the trigger                   |
| `severity`    | `critical`, `high`, `warning` or `info`            |
| `state`       | `firing` (opening) or `resolved` (closing)         |
| `externalId`  | Stable identifier of the alert cycle at the source |
| `serviceHint` | Hint about which service is affected               |
| `labels`      | Additional labels from the source                  |
| `externalUrl` | Link back to the originating tool                  |

Free-form severities (`P1`, `sev2`, `error`, `warn`…) are mapped onto aciona.me's closed set. See [Severities](/en/reference/severities).

## 3. Routing

With the alert normalized, aciona.me answers three questions, in order:

<Steps>
  <Step title="Which service is affected?">
    From the default service configured on the alert source, or from the service hint (`serviceHint` / `service` label) sent by the tool. If the hint points at a service that does not exist yet, it can be registered automatically.
  </Step>

  <Step title="Which team owns that service?">
    Every service has a responsible team. That link is what turns a technical alert into human responsibility.
  </Step>

  <Step title="Who is on call for that team right now?">
    The team's active schedule determines the current responder, honoring timezone, rotation and any override in effect.
  </Step>
</Steps>

## 4. Incident

If no matching open incident exists, a new one is created with status `triggered`, linked to the organization, the service, the team and the responder.

If an open incident for the same source **already exists**, the alert is aggregated into it instead of creating a duplicate. See [Grouping and auto-resolution](/en/incidents/grouping-and-auto-resolution).

## 5. Notification

The incident triggers notifications through the configured channels: email, push (browser and mobile), Slack and Microsoft Teams. Once at least one channel delivers, the incident moves to `notified`.

## 6. Acknowledgement and escalation

From there the clock is running. If nobody acknowledges the incident within the timeout, it is automatically escalated to the next target — the next participant in the schedule or the next level of the policy. If escalation runs out of targets, the organization owners are notified.

Acknowledging, taking ownership or resolving the incident stops escalation.

## 7. Resolution

An incident can be resolved by a person in the dashboard or **automatically**, when the originating tool sends the recovery event. Once resolved, it can be closed.

<Card title="See the full lifecycle" icon="siren" horizontal href="/en/incidents/lifecycle">
  Every status, who can change each one, and what shows up on the timeline.
</Card>