> 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/notifications.md).

# Notifications

How many notifications ilert sent over each channel, optionally broken down by user.

The notification report counts the messages ilert actually sent — emails, push, SMS, voice calls and messenger messages — over the period you choose. Use it to see which channels your team relies on, and who is absorbing the volume.

It is available on every plan. Parameters, filters, date handling and exports work the same way on all three reports — see [Overview](/reports/overview.md) for those.

{% hint style="info" %}
A notification is one message to one person over one channel, so a single alert routinely produces several. One alert that pages two responders by push and SMS counts as one alert in the [alert report](/reports/alerts.md) and four notifications here.
{% endhint %}

## Channels

Notifications are counted per channel. Every chart and table uses the same seven, plus a **Total** column:

| Channel      | Delivered as                           |
| ------------ | -------------------------------------- |
| **Email**    | An email to a contact address          |
| **Android**  | A push notification to the Android app |
| **iPhone**   | A push notification to the iOS app     |
| **SMS**      | A text message to a phone number       |
| **Voice**    | A phone call to a phone number         |
| **WhatsApp** | A WhatsApp message                     |
| **Telegram** | A Telegram message                     |

Which of these a person can receive is set by their own [notification settings](/alerting/configure-alerting/notification-settings.md). A channel nobody has configured stays at zero.

## Chart

A bar chart of notification volume over the range, one color per channel.

Hovering a bar opens a tooltip listing the names and values at that point; the list scrolls when it is long.

### Grouping by user

Set **Group by** to **User** and each bar splits by person and channel together. The legend entry is then the user's name followed by the channel — `Ali Kim iPhone` — and only pairs that actually received something in the range are listed, so a person who was never sent an SMS contributes no SMS entry.

The swatch beside each entry carries both colors: a square in the user's color, with a smaller square tucked into its bottom-right corner in the channel's color. That is what lets you scan one person's channels or one channel's people in the same legend.

{% hint style="info" %}
User colors are derived from a hash of the user's identifier, not their name, so renaming somebody does not change their color.
{% endhint %}

## Table

Below the chart, one row per day, week or month according to **Time granularity**, with a column per channel and a **Total**. Grouping by user adds a **User** column and one row per user and period. **Download** saves the table as CSV.

## Report parameters

### Time granularity <a href="#time-granularity" id="time-granularity"></a>

**Day**, **Week** or **Month** sets what one bar and one row represent.

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** or **User**. Grouping by user splits every bar and adds a **User** column to the table.

## Filters

| Filter    | Selects by                                                                                                                |
| --------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Teams** | Restricts the report, and the **Users** filter, to members of the selected [teams](/users-and-access-management/teams.md) |
| **Users** | The person the notification was sent to                                                                                   |

Both carry an **Includes** / **Excludes** toggle. **Excludes** takes precedence: a user matched by an exclude filter is left out even if another filter would have included them.

## FAQ

### Does a high SMS count cost me anything?

It depends on your plan. The Free plan includes 100 SMS and voice notifications; Pro and above are unlimited. See [ilert pricing](https://www.ilert.com/pricing). Either way, this is the fastest way to see where that volume is going.

### Why does one person have far more notifications than everybody else?

Usually notification rules rather than workload: somebody who has configured push, email and SMS receives three notifications where a colleague with push alone receives one. Compare the [on-call report](/reports/on-call-duties.md), which counts alerts per person rather than messages.

### A channel shows zero, but I know we use it.

Check the date range first, then the person's contact methods. A channel only produces notifications once somebody has a contact for it and a notification rule that uses it.

### Can I see whether a notification was delivered?

Not here — this report counts volume. For a specific alert, the **Timeline** on the [alert](/alerting/working-with-alerts/alert-view.md) lists each notification, including any that ilert held back or dropped and the reason why.


---

# 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/reports/notifications.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.