> 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/getting-started/readme.md).

# Welcome to ilert

What ilert does, how an event becomes an alert, when to declare an incident, and where to find each part of the documentation.

ilert receives events from your monitoring, ticketing, and other tools, turns them into alerts, and notifies whoever is on call, escalating if that person does not respond. When a response needs coordinating, you declare an incident, and post status updates to tell the people who depend on you.

To try it, [sign up](https://app.ilert.com/signup) and follow the [Quick start](/getting-started/quick-start-guide.md). It takes you from an empty account to a real notification on your phone in about 10 minutes.

## Find what you need

<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>Alerting</strong></td><td>Turn events into alerts: alert sources, grouping, support hours, maintenance windows, notification rules, event flows, and heartbeat monitoring.</td><td><a href="/alerting/overview.md">Overview</a></td></tr><tr><td><strong>On-call management</strong></td><td>Escalation policies, on-call schedules, and coverage requests.</td><td><a href="/on-call-management-and-escalations/escalation-policies.md">Escalation policies</a></td></tr><tr><td><strong>Incidents &#x26; status pages</strong></td><td>Coordinate a response, post status updates, write postmortems, and run public or private status pages.</td><td><a href="/incidents-and-status-pages/getting-started.md">Getting started</a></td></tr><tr><td><strong>ChatOps</strong></td><td>Receive and act on alerts in Slack, Microsoft Teams, or Google Chat.</td><td><a href="/chatops/overview.md">Overview</a></td></tr><tr><td><strong>Call routing</strong></td><td>Give your team one phone number that reaches whoever is on call. An add-on from the Pro plan.</td><td><a href="/call-routing/getting-started-with-call-routing.md">Getting started with call routing</a></td></tr><tr><td><strong>AI &#x26; agents</strong></td><td>AI features in everyday workflows, autonomous agents, and MCP servers.</td><td><a href="/ai-and-agents/introduction.md">Overview</a></td></tr><tr><td><strong>Users &#x26; access</strong></td><td>Roles, teams, single sign-on, and two-factor authentication.</td><td><a href="/users-and-access-management/user-roles-and-permissions.md">User roles and permissions</a></td></tr><tr><td><strong>Reports</strong></td><td>Alert, on-call duty, and notification reports, with CSV export.</td><td><a href="/reports/overview.md">Overview</a></td></tr><tr><td><strong>Mobile app</strong></td><td>Accept, escalate, and resolve alerts from iOS or Android.</td><td><a href="/mobile-app/getting-started-with-ilert-mobile-app.md">Getting started with ilert mobile app</a></td></tr><tr><td><strong>Integrations</strong></td><td>Inbound integrations, outbound integrations, and deployment pipelines.</td><td><a href="/integrations/types-of-integrations.md">Types of integrations</a></td></tr></tbody></table>

The rest of the documentation lives in its own sections:

* [**Developers**](https://docs.ilert.com/developer-docs/): the REST API reference, client libraries, the Terraform provider, and building ilert apps.
* [**What's new?**](https://docs.ilert.com/changelog/): release notes by month.
* [**Knowledge base**](https://docs.ilert.com/knowledge-base/): answers to common questions.
* [**Trust center**](https://docs.ilert.com/trust-center/): security, compliance, and legal documentation.

## Connect your tools

ilert has more than 150 inbound integrations. These are common starting points:

| To get alerts from                 | Start with                                                                                                                                                                                                        |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Infrastructure monitoring          | [Prometheus](/integrations/inbound-integrations/prometheus.md), [Amazon CloudWatch](/integrations/inbound-integrations/amazon-cloudwatch.md), [Datadog](/integrations/inbound-integrations/datadog.md)            |
| Application errors and performance | [Sentry](/integrations/inbound-integrations/sentry.md), [New Relic](/integrations/inbound-integrations/new-relic.md), [AppDynamics](/integrations/inbound-integrations/appdynamics.md)                            |
| Website and service uptime         | [Pingdom](/integrations/inbound-integrations/pingdom.md), [UptimeRobot](/integrations/inbound-integrations/uptime-robot.md), [StatusCake](/integrations/inbound-integrations/statuscake.md)                       |
| Security tools                     | [AWS GuardDuty](/integrations/inbound-integrations/guardduty.md), [Azure Sentinel](/integrations/inbound-integrations/azure-alerts/sentinel.md), [CrowdStrike](/integrations/inbound-integrations/crowdstrike.md) |

If your tool is not listed in the [inbound integrations](/integrations/inbound-integrations.md), it can still reach ilert through the [Events API](/developer-docs/api-samples/creating-alerts-through-events.md) or by [email](/integrations/inbound-integrations/email.md).

To see what changed before an alert, connect your CI/CD tooling as well: [GitHub](/integrations/deployment-integrations/github.md), [GitLab](/integrations/deployment-integrations/gitlab.md), or [Argo CD](/integrations/deployment-integrations/argo-cd-deployment-pipeline.md). These send [deployment events](#deployment-events), not alerts.

## How ilert works

1. A tool sends an [event](#event) to an [alert source](#alert-source).
2. The alert source decides what the event means. It opens an [alert](#alert), adds the event to an open alert, accepts or resolves an open alert, or filters the event out.
3. The alert source's [escalation policy](#escalation-policy) decides who is notified, often through an [on-call schedule](#on-call-schedule).
4. Each person receives [notifications](#notification) over the channels they set up.
5. Someone accepts the alert, which stops the escalation. The alert is resolved once the problem is fixed, by a person or by the tool that raised it.
6. If the response needs coordinating, you declare an [incident](#incident). A [status update](#status-update) posted from it reaches your [status pages](#status-page) and subscribers.

## Core concepts

### Event

An event is the payload a tool sends to ilert. Its integration key says where it goes: an alert source, or an event flow that routes it to one. See [How ilert processes events & alerts](/alerting/overview/understanding-event-flows.md).

### Alert source

An alert source receives events and decides what each one does. It holds the integration key and the filtering and grouping settings, and names the escalation policy to use. Alert sources are also called **inbound integrations**. See [Alert sources](/alerting/configure-alerting/alert-sources.md).

### Alert

An alert is the actionable record that drives notifications. An alert source creates it from one or more events, and it moves through three states:

| State      | Means                                                                                                        |
| ---------- | ------------------------------------------------------------------------------------------------------------ |
| `PENDING`  | Nobody has accepted the alert yet. It escalates through its policy until someone does or the policy runs out |
| `ACCEPTED` | Someone has taken ownership, and escalation stops                                                            |
| `RESOLVED` | The problem is fixed. A resolved alert cannot be reopened; a later event creates a new one                   |

See [Working with alerts](/alerting/working-with-alerts.md).

### Escalation policy

An escalation policy is an ordered list of rules. Each rule names one or more targets (users, teams, or on-call schedules) and how long they have to respond before the next rule applies. See [Escalation policies](/on-call-management-and-escalations/escalation-policies.md).

### On-call schedule

An on-call schedule decides who is on call at any moment. Only one user per schedule is on call at a time. Name a schedule in an escalation policy, and alerts reach whoever is on call then. See [On-call schedules](/on-call-management-and-escalations/on-call-schedules.md).

### Notification

A notification is one message to one user over one channel: push, SMS, phone call, WhatsApp, Telegram, or email. Each user sets their own rules, so two people on the same escalation policy can be reached differently. See [Notification settings](/alerting/configure-alerting/notification-settings.md).

### Incident

An incident is the coordination record above alerts. Declare one when a response needs coordinating, whether or not an alert fired: it links any alerts involved, gathers responders, and keeps a shared timeline. An incident publishes nothing by itself. See [Incidents](/incidents-and-status-pages/incidents.md).

### Status update

A status update is the public message you post, usually from an incident. It is what appears on your status pages and reaches subscribers. See [Status updates](/incidents-and-status-pages/status-updates.md).

### Service

A service is a capability your users care about, such as Checkout or Login. It receives no events and owns no escalation policy. Alerts and status updates attach to it, status pages display it, and people subscribe to it. Setting a service's status notifies nobody; a status update does. See [Services](/incidents-and-status-pages/services.md).

### Status page

A status page shows the current state of your services and the status updates you post. It can be public or private. See [Status pages](/incidents-and-status-pages/status-pages.md).

### Actions, alert actions, and connectors <a href="#connector-and-alert-action-aka-outbound-integration" id="connector-and-alert-action-aka-outbound-integration"></a>

An **action** runs work when an alert or incident changes, or when someone starts it: it opens a Jira issue, calls a webhook, or sends an email. Actions are also called **outbound integrations**. See [Actions](/integrations/actions.md).

**Alert actions** are the older form, and run on alerts only. New accounts have actions, and older accounts generally still have alert actions. The sidebar shows whichever your account has, never both. See [Outbound integrations](/integrations/outbound-integrations.md).

A **connector** stores how ilert reaches the target system: its URL and its credentials. Create it once, and reuse it in as many actions or alert actions as you need.

### Deployment events

A deployment event is a report from your CI/CD tooling of what it shipped. ilert matches these reports to alerts, so a responder sees what changed before the alert. See [Deployment events](/alerting/deployment-events.md).

## Get help

If these docs do not answer your question, contact <support@ilert.com>. The current state of ilert itself is at [status.ilert.com](https://status.ilert.com).


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ilert.com/getting-started/readme.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.