> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/alerting/overview.md).

# Overview

Alerting is how a signal from one of your tools becomes a page to a human. An event arrives, an alert source decides what it means, and an escalation policy decides who hears about it.

## How an event becomes a page

{% stepper %}
{% step %}

## An event arrives

A monitoring, logging, or ticketing tool sends an event to an **alert source** — over the Events API, by email, or through one of the built-in integrations. The event carries a payload describing what changed.
{% endstep %}

{% step %}

## The alert source decides what it means

The alert source owns every parsing and grouping rule. It can filter the event out, group it into an alert that is already open, or treat it as something new. This is where noise is controlled.
{% endstep %}

{% step %}

## An alert is created or updated

A new **alert** appears in **Alerts**, or an existing one absorbs the event. An alert is the actionable record: it has a status, an owner, and a timeline.
{% endstep %}

{% step %}

## Responders are notified

The alert source's **escalation policy** decides who is notified and in what order. Each person is reached through the channels set in their own notification rules — push, SMS, voice, email, or chat.
{% endstep %}
{% endstepper %}

## Where incidents fit

Most alerts never become incidents. The two are different objects with different jobs:

* An **alert** is one actionable signal. It is created automatically and resolved when the underlying problem is fixed.
* An **incident** is a coordination record you declare deliberately when something has business impact — it gathers responders, links the alerts involved, and keeps a shared timeline.

Declaring an incident is a decision a person makes, not a stage every alert passes through. An incident also publishes nothing on its own; a **status update** posted from it is what reaches your status pages and subscribers.

{% hint style="info" %}
If you are looking for the customer-facing side of this — services, incidents, and status pages — see [Incidents & status pages](/incidents-and-status-pages/getting-started.md).
{% endhint %}

## Alert states

| State      | Means                                                                                                                 |
| ---------- | --------------------------------------------------------------------------------------------------------------------- |
| `PENDING`  | Not yet acknowledged. The alert is escalating through its policy.                                                     |
| `ACCEPTED` | Someone has taken ownership. **Escalation stops** — ilert will not page anyone else.                                  |
| `RESOLVED` | The problem is fixed. No further notifications. A resolved alert cannot be reopened; a later event creates a new one. |

## Core objects

| Object                | What it is                                                                                                                                                       |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Event**             | The raw payload a tool sends. Routed to an alert source by its integration key, and visible in that source's logs.                                               |
| **Alert source**      | Receives events. Owns the integration key, the escalation policy, and every filtering and grouping setting. Also called an *inbound integration*.                |
| **Alert**             | The actionable record created from one or more events.                                                                                                           |
| **Escalation policy** | The ordered rules deciding who is notified, and how long each level has to respond.                                                                              |
| **Notification**      | One message to one person over one channel.                                                                                                                      |
| **Alert action**      | Optional. Automation that fires when an alert is created, updated, or resolved — opening a Jira ticket, posting to Slack. Also called an *outbound integration*. |
| **Event flow**        | Optional. A routing layer above alert sources, with its own ingest URL, for conditional routing and transformation.                                              |

## In this section

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>How ilert processes events &#x26; alerts</strong></td><td>The full lifecycle, including grouping, rate limits, and suppression.</td><td><a href="/pages/CLm3soezNSLZDHkkZHUG">/pages/CLm3soezNSLZDHkkZHUG</a></td></tr><tr><td><strong>Configure alerting</strong></td><td>Connect tools, set up alert sources, support hours, and notification behavior.</td><td><a href="/pages/lg2dbIpRCaQotRqQNDpN">/pages/lg2dbIpRCaQotRqQNDpN</a></td></tr><tr><td><strong>Work with alerts</strong></td><td>Filter, triage, accept, and resolve alerts day to day.</td><td><a href="/pages/dg1b4NM0pFpujDXvKEdT">/pages/dg1b4NM0pFpujDXvKEdT</a></td></tr><tr><td><strong>Data retention</strong></td><td>How long ilert keeps events, alerts, and their logs.</td><td><a href="/pages/rozUWSWPXPavDlTeEMk5">/pages/rozUWSWPXPavDlTeEMk5</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ilert.com/alerting/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.