> 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/reports/alerts.md). # Alerts Alert volume, MTTA and MTTR over time, grouped by alert source or escalation policy and filtered down to the alerts you care about. The alert report answers three questions about a period: how many alerts you got, how long they waited to be accepted, and how long they took to resolve. Group the numbers by alert source or escalation policy to see which part of your estate produces them. The report needs the **Pro** plan or higher. Parameters, filters, date handling and exports work the same way on all three reports — see [Overview](/reports/overview.md) for those.
The Alerts tab of the reports page. Three widgets read Alert volume 110, MTTA 21h 20m and MTTR 5d 18h. Below them a Metric selector holds one chip, Alert volume, and a line chart plots weekly counts from 2026-W25 to 2026-W38, peaking at 38.

Widgets summarize the whole range; the chart breaks it down by the time granularity you pick.

{% embed url="" %} Volume, MTTA and MTTR, what the averages leave out, and the report parameters {% endembed %} ## Metrics Three figures sit above the chart, each covering the whole selected range with your filters applied: | Widget | Counts | Excludes | | ---------------- | -------------------------------------------------------------------- | ---------------------------- | | **Alert volume** | Every alert created in the range | — | | **MTTA** | Average time from alert creation to the first responder accepting it | Alerts nobody accepted | | **MTTR** | Average time from alert creation to resolution | Alerts that are not resolved | Those exclusions are the part worth remembering. An alert that nobody ever accepted does not make MTTA worse — it drops out of the average entirely. A week in which half the alerts were ignored can therefore show a better MTTA than a week in which they were all accepted late. Read **Alert volume** alongside the averages, not on its own. {% hint style="info" %} MTTA measures acceptance, and accepting an alert stops escalation. So MTTA is the time until someone took ownership, not the time until the problem was fixed — that is MTTR. {% endhint %} ### Choosing what the chart shows **Metric** under the widgets controls the chart and the table. With **Group by** set to **None**, it is a multi-select: pick **Alert volume**, **Mean time to acknowledge (MTTA)** and **Mean time to resolution (MTTR)** in any combination. Counts and durations do not share a scale, so when you mix them the chart draws a second Y-axis on the right for MTTA and MTTR. With **Group by** set to anything else, it becomes a single choice — one metric, one line per group. ## Chart The chart plots your selected metrics over the range, one point per [time granularity](#time-granularity) period. Hovering a point opens a tooltip listing the names and values at that point; the list scrolls when it is long. Clicking anywhere on the chart opens the [alerts behind that point](#viewing-the-alerts-behind-a-number). Whenever a single metric is selected — which grouping forces — tooltip entries are sorted by value, largest first, so the worst offender in that period is at the top. With several metrics selected they keep the chart's own order instead. {% hint style="info" %} Legend colors are derived from a hash of the resource's type and ID, not its name or its position in the list. Rename an alert source and its line keeps its color, which is what makes two reports taken months apart comparable at a glance. {% endhint %} ## Table Below the chart, the same data as rows — one per day, week or month, according to **Time granularity**. **Download** saves it as CSV. {% hint style="warning" %} **The table and the CSV do not always hold the same columns.** When **Group by** is anything other than **None**, the table shows only the metric you selected, but the downloaded CSV contains all three. If you need every metric and a grouping at once, export rather than read on screen. {% endhint %} ## Report parameters ### Time granularity **Day**, **Week** or **Month** sets what one point and one row represent. Counts are totals for the period; MTTA and MTTR are averages over it. Because countries disagree on when a week begins, **Week** carries a badge showing the numbering in force: a green badge naming a locale means it came from your account, red means it came from your own user profile or the German fallback, orange `ISO` means that locale is unsupported and ISO 8601 was substituted, and a blue short label such as `M,4` means you chose it yourself. Click the badge, pick an entry under **Week numbering**, and click **Apply**; **Reset** returns to the default. The choice is saved in your browser for your user and account, and applies to all three reports — but only in that browser. [Week numbering](/reports/overview.md#time-granularity-and-week-numbering) covers the four schemes and how the default is resolved. ### Group by **None**, **Alert Source** or **Escalation policy**. Grouping splits the chart into one series per alert source or policy, and restricts you to a single metric. ## Filters **Teams**, where you have them, narrows both the report and the filters below it. The rest: | Filter | Selects alerts by | | ----------------------- | ----------------------------------------------------------------------------- | | **Alert Sources** | The alert source that created the alert | | **Escalation policies** | The escalation policy the alert escalated through | | **Responders** | Who accepted or resolved the alert | | **Alert priority** | **High priority** or **Low priority** | | **Severity** | The severity on the alert: **1** to **5**, or **None** for alerts without one | | **Merged alerts** | Whether alerts merged into another are counted | | **Labels** | Labels carried by the alert itself |
The Filters section of the alert report panel: Teams, Alert Sources, Escalation policies and Responders each with an Includes and Excludes toggle and set to All; Alert priority set to All; Severity as toggle buttons 1 to 5 plus None; Merged alerts set to Exclude merged alerts; and Labels with a Filter button. Apply and Clear filter sit at the bottom.

Severity, Merged alerts and Labels sit below the fold — scroll the panel to reach them.

**Alert priority** offers **All**, **High priority** and **Low priority**. High-priority alerts escalate through the whole policy; low-priority alerts stop at the first escalation rule. **Severity** is a multi-select of toggle buttons, colored to match the severity badges elsewhere in ilert. Selecting none is the same as selecting all. **Merged alerts** offers **Exclude merged alerts**, **Include merged alerts** and **Only merged alerts**, and defaults to excluding them. When you [merge alerts](/alerting/working-with-alerts/merging-alerts.md), the child alerts are the ones left out — the main alert still counts — so one duplicated problem contributes one alert to the report rather than five. Switch to **Only merged alerts** to see how much merging your team is doing. **Labels** builds conditions against alert labels. These are not something you configure: ilert creates them as alerts arrive carrying labels from your alert sources, so the list is empty until some have. Click **Filter**, choose a label key, an operator — **is equal to**, **is any of**, **is not equal to** or **is not any of** — and one or more values. Applied conditions appear as chips under the filter, and you can add up to 20. {% hint style="warning" %} **Alert Sources**, **Escalation policies** and **Responders** are combined with *or*, not *and*. An alert is included when it matches any one of them — so selecting an alert source and a responder returns that source's alerts plus that person's alerts, not just the overlap. {% endhint %} ## Viewing the alerts behind a number Click a point on the chart, or **View alerts** on a table row, to list the individual alerts that produced it. The table has one row per alert: **ID**, **Summary**, **Alert Source**, **Escalation policy**, **Reported On**, **TTA** and **TTR**. A colored stripe runs down the left of the **ID** cell in the alert's severity color; alerts with no severity get no stripe. **Download** exports the list. A dash in **TTA** or **TTR** means the alert was never accepted, or is not resolved yet — the same alerts the MTTA and MTTR averages leave out. Above the table: * **Search** filters the rows. It splits what you type on spaces and keeps a row only if **every** word appears somewhere in it — the ID, summary, alert source, escalation policy, reported time, TTA or TTR. Matching is on substrings, so `pay` finds `Payments`, and two words can match two different columns. * **Date** moves between days, weeks or months, following your **Time granularity**. * A third filter appears when **Group by** is not **None**, to pick which alert source or escalation policy you are looking at. {% hint style="info" %} The **Reported On** format follows **Time granularity**. At **Day** the rows are all from one day, so only the time is shown; at **Week** and **Month** the date is shown too. {% endhint %} ## Printing **Print** at the top right of the page opens your browser's print dialog with the report laid out for paper, in the light theme regardless of the theme you are using. From there you can print it or save it as PDF. ## FAQ ### Why did MTTA improve in a week when we clearly responded worse? Because unaccepted alerts are excluded from MTTA. If more alerts went unaccepted that week, the ones that remain in the average may well be the fast ones. Compare **Alert volume** and the alert list for the same period before reading it as an improvement. ### My alert source is missing from the filter list. Check the **Teams** filter first. Selecting teams narrows every filter below it to the resources belonging to those teams, so an alert source in another team disappears from the list. ### Can I report on incidents rather than alerts? No. This report covers alerts. Incidents, their responders and their timelines are not reported on here. ### The numbers do not match what I counted in the alert list. Three defaults usually explain it: merged alerts are excluded unless you change **Merged alerts**, the range is read in your ilert profile's time zone rather than your browser's, and **Date range** includes both end days in full. --- # 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/reports/alerts.md?ask=&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.