For the complete documentation index, see llms.txt. This page is also available as Markdown.

Overview

How ilert turns events from your tools into alerts, and how alerts reach the person who can do something about them.

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

1

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.

2

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.

3

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.

4

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.

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.

If you are looking for the customer-facing side of this — services, incidents, and status pages — see Incidents & status pages.

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

Last updated

Was this helpful?