> 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/on-call-duties.md). # On-call duties Time on call, alerts handled and time spent on alerts, per person and per day, across your schedules. The on-call report shows how the on-call load is distributed: who was on call, for how long, how many alerts reached them, and how much of that time went into working alerts. Use it to spot the person carrying a rotation on their own, or a schedule that is quiet enough to merge. The report needs the **Scale** plan or higher. Parameters, filters, date handling and exports work the same way on all three reports — see [Overview](/reports/overview.md) for those. ## Metrics | Metric | Measures | | ----------------------- | ------------------------------------------------------ | | **Time on-call** | Total time the user was on call in the period | | **# Alerts** | Number of alerts that reached the user | | **Time spent on alert** | Time the user spent on alerts until they were resolved | **Metric** above the chart chooses which one is plotted. Unlike the [alert report](/reports/alerts.md), it is a single choice — but the table below always shows all three, so you do not need to switch to compare them. {% hint style="info" %} **Time on-call** counts the shift, not the effort. Somebody who was on call for a week and never got paged still shows seven days. Read it next to **# Alerts** and **Time spent on alert** to tell a heavy rotation from a long quiet one. {% endhint %} ## Chart A bar chart of the selected metric over the range, with one color per user. Hovering a bar opens a tooltip naming every user in that period and their value; the list scrolls when it is long. {% hint style="info" %} Legend colors are derived from a hash of the user's identifier, not their name. Someone who changes their name keeps their color, so a report from six months ago still lines up with today's. {% endhint %} ## Table The table under the chart has two tabs: * **Summary** — one row per user, with all three metrics for the whole range. * **Shifts by day** — the same users, each expandable with the chevron into one row per day. The day rows add **Day**, **Start** and **End**, so you can see how a total was accumulated and where a shift began and ended.
The Shifts by day tab of the on-call report. Ali Kim's row, showing 12d 14h on call, is expanded into day rows with columns Day, Start and End - for example 01/08/2026 from 00:00 to 23:59 counting as 1d, and 02/08/2026 from 00:00 to 09:59 counting as 10h.

Expanding a user shows the shifts that add up to their total, including partial days.

Half-days are normal here: a rotation that hands over at 10:00 produces a 14-hour row on the day it starts and a 10-hour row on the day it ends. **Download** saves the table as CSV, and **View alerts** on a row opens the alerts behind that person's numbers. ## Report parameters ### Time granularity **Day**, **Week** or **Month** sets what one bar represents. 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. This report has no **Group by** parameter. It is always grouped by user. ## Filters **Teams**, where you have them, narrows both the report and the filters below it. | Filter | Selects by | | ------------- | ---------------------------------------------------------------------------------------------------- | | **Schedules** | The [on-call schedule](/on-call-management-and-escalations/on-call-schedules.md) the shift came from | | **Users** | The person on call | {% hint style="warning" %} **Schedules** and **Users** are combined with *or*, not *and*. Selecting a schedule and a person returns everyone on that schedule plus that person's shifts everywhere — not only that person's shifts on that schedule. {% endhint %} ## Viewing the alerts behind a number **View alerts** on a table row lists the alerts that person handled, one row per alert: **ID**, **Summary**, **Alert Source**, **Escalation policy**, **Reported On**, **TTA** and **TTR**. 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. * **User** switches to another person, offering the people in the current report. * A **Date** filter appears when you opened the list from the **Shifts by day** tab, listing that person's days. **Download** exports the list as CSV. ## FAQ ### Can I count only the alerts that arrived at night? No. There is no time-of-day narrowing in this report. Set **Time granularity** to **Day** and read the daily rows, or export the CSV and filter it yourself. ### Somebody is missing from the report. They had no on-call time in the range. The report covers shifts, so a person who is only ever reached as a direct escalation target — never through a schedule — has no time on call to show. ### Does this report show who was notified? No, it shows who was on call and what reached them. For notification counts per channel, use the [notifications report](/reports/notifications.md). --- # 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/on-call-duties.md?ask=&goal= ``` `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.