> 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/alerting/configure-alerting/support-hours.md). # Support hours Define support hours to set an alert's priority by whether it arrives in or out of the hours your team covers. Define support hours for alert sources and call routing numbers to manage the priority of alert notifications and to route calls to different targets. Support hours **switch** an alert's priority, they do not withhold it. Which way round depends on the alert source's [notification priority](/alerting/configure-alerting/alert-sources.md#notification-priority): with **High in hours, low priority out of hours**, an event arriving outside the window you define creates a `LOW` priority alert instead of a `HIGH` one, and **Low in hours, high priority out of hours** does the reverse. A `LOW` alert uses only the first escalation rule and never advances past it, so if you expected silence overnight and got a quiet page instead, this is why. {% hint style="info" %} Support hours require the [Scale plan](https://www.ilert.com/pricing) or higher. {% endhint %} ## Create support hours 1. In the sidebar, go to **Alerting** → **Support hours** 2. Click on **Create new support hours** 3. Select the team to which the support hours belong to (if any), give it a name, pick the **Timezone** your hours are read in, and enter the hours you cover 4. Click **Save**. You can now use these support hours in [alert sources](/alerting/configure-alerting/alert-sources.md#notification-priority) and call routing numbers to set notification priority of alerts and route incoming call routing calls to different targets based on support hours. You can also have a [recurring on-call schedule](/on-call-management-and-escalations/on-call-schedules/recurring-schedules.md#follow-support-hours-respects-holidays) follow these support hours, so your on-call coverage respects the same holidays. {% embed url="" %} ## Enter the hours you cover Your weekly hours are a list of ranges. Each row reads **From** a day and a time **→ To** a day and a time, and a range can run from any point in the week to any other — including across midnight and across the weekend. | To cover | Enter | | -------------------------------------- | --------------------------------------------------------- | | A working day | **From** `Mon` `09:00` **To** `Mon` `17:00` | | A night shift | **From** `Tue` `22:00` **To** `Wed` `06:00` | | The whole weekend, in one piece | **From** `Fri` `17:00` **To** `Mon` `09:00` | | A split shift, with lunch out of hours | Two rows: `Mon` `09:00`–`12:00` and `Mon` `13:00`–`17:00` | Click **Add hours** for another row, and the **×** at the end of a row to remove it. Ranges that overlap or touch are merged into one row when you leave the row and again when you save, so the rows always show exactly what is stored. {% hint style="info" %} To cover a day to its very end, set **To** to `00:00` **on the next day**, not to `23:59`. Midnight is an ordinary point in the week here: a range ending at `00:00` and one starting there join into a single stretch of coverage, and nothing is left uncovered in between. Support hours written before ranges existed keep the `23:59` endings they were saved with, and the minute after them stays uncovered. Change one to `00:00` on the next day to close it. {% endhint %} ### Start from a preset **Office hours** fills in Mon–Fri 09:00–17:00, **Outside office hours** covers everything around it, and **24/7** covers the whole week — the rows then read **Every day, all day (24/7)**. A preset replaces the hours above it and changes nothing else. Your **Holiday exceptions** stay exactly as they were, which is worth a second look after switching between **Office hours** and **Outside office hours**: an exception that took a day *out* of office hours now takes it out of the night shift instead. ### When the editor refuses a row These checks apply to a row you type or edit. Ranges that are already stored, or that came out of a merge, are left as they are. | The row says | Cause | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Enter both times as HH:mm. | A time is missing or incomplete. Times are whole minutes | | From and To are the same. To cover the whole week, use 24/7. | Equal endpoints mean the whole week, and a typo should not switch on round-the-clock coverage. Use the **24/7** preset when that is what you want | | To is earlier than From on the same day, so this would run for almost a whole week. To run past midnight, choose the next day as To. | `Mon 17:00` **To** `Mon 09:00` is a range that wraps all the way around. For a night shift, pick the next day in **To** | **Save** stays disabled while any row is invalid. One support hour holds at most 84 ranges. ## See what is covered right now The support hours list and each support hour's own page carry a **Right now** badge reading **In hours** or **Out of hours**, with the moment it changes next to it — `Until 17:00` for later today, `Until Mon 09:00` further out, or **no change ahead** when no next change is in sight, as for 24/7 coverage with no holiday exception coming, and for a support hour with no weekly hours and no covered holiday ahead. Holiday exceptions count towards the badge, so a covered holiday reads **In hours**. The times are read on the **support hour's own timezone**, not yours. Its own page and the editor show its clock beside the change, as in `Until 17:00 · Wed 14:32`, and name the zone in the **Timezone** field; a list row has no space for a second clock, so there a timezone that is not yours is named next to the time instead. The support hour's own page lists your ranges as text — `Mon 09:00–17:00` within a day, `Fri 17:00 → Mon 09:00` for one that runs into a later day — next to the same week drawn as a chart: one column per day, midnight at the top and midnight at the bottom, filled where you cover it. The chart draws the weekly hours only. A holiday exception moves the **Right now** badge but not the chart, so on a holiday nobody covers the badge reads **Out of hours** over a day the chart still shows as filled. The list draws that chart in its **Support hours** column, with a marker for the current moment. Under it, a line counts the support hour's holiday exceptions and opens them in a popover — what is still ahead first, with **Show past** for the ones behind us — rather than taking you off the list. The timezone sits there too, shown only when it is not your own. A support hour with no weekly hours says so over the empty week. The editor shows the same badge and the same week under the rows, following your edits before you save them. ## Holidays The holiday feature is a part of Support hours in ilert. It provides a smart way to handle exceptions to your regular support schedule—like national holidays, company-wide days off, or any non-standard workday—without needing to adjust your on-call rotations or escalation policies manually. In the sidebar, go to **Alerting** → **Support hours** and open the support hours you want to adjust. Its **Holiday exceptions** table sits below the weekly hours and lists every exception with its dates and support status. Click **Edit** to change them. Every exception carries a **Support status for this period**, and that status is what it does to the weekly hours. **Out of hours** takes the period out of your support hours — a public holiday nobody covers. **In hours** puts it in, for a day you do cover although the weekly hours say otherwise. To take a public holiday calendar, click **Import holidays from calendar**. Choose the **Country**, **Region / State** and **Year**, untick any date you do not want, then set the **Support status for this period** that every imported holiday gets. Click **Import**. The status starts on **In hours**, so switch it to **Out of hours** if these are days nobody covers. **All day** is ticked by default, and imports each holiday from `00:00` on its first day to `00:00` after its last, so the whole day is covered. Untick it to give the imported holidays a start and an end time instead. To add a single date yourself, click **Add holiday exception**, give it a **Name**, a **Start** and **End**, and a **Support status for this period**, and click **Add**.
The Add holiday exception dialog in ilert, with Name, Start and End fields and a Support status for this period toggle offering In hours and Out of hours.

One exception, one period, one support status.

Both **Import** and **Add** only fill the **Holiday exceptions** table in the editor. Click **Save** to store them, which takes you back to the support hours list. Leaving the page first loses them. ## Support hours defined on an alert source itself An alert source can carry support hours of its own instead of referencing one of yours. These predate support hours as a separate object, and they are **one window per day**: they cannot run past midnight or hold two windows on the same day. To cover a night, a weekend or a split shift on an alert source, create support hours under **Alerting** → **Support hours** and pick them in the alert source's **Choose support hours** field. An alert source that still carries its own offers two links for the move: **Migrate the above support hours to account-level support hours**, which creates a support hour from what is already there, and **Use existing account-level support hours**, which picks one you have. The same support hours can then be referenced by as many alert sources, call flows and event flows as you like, and followed by up to 200 schedules. ## Use support hours in recurring on-call schedules Support hours — including their holiday exceptions — can drive on-call coverage directly. In a [recurring schedule](/on-call-management-and-escalations/on-call-schedules/recurring-schedules.md), set a layer's coverage to **Follow support hours (respects holidays)** and pick a support hour. The layer then follows that support hour's weekly hours and holidays, so the rotation automatically pauses on non-working holidays and picks up on days with extra coverage — no manual restriction editing required. Each range becomes one stretch of on-call coverage, so a weekend reaches the schedule as one unbroken block from Friday evening to Monday morning rather than as three nightly pieces cut at midnight. Who is on call inside that block still follows the layer's rotation, and holiday exceptions still cut it. Coverage is copied into the schedule, not linked live, so historical shifts never change. When you edit the support hour, every schedule that follows it is re-synced going forward. {% hint style="warning" %} A schedule can only follow support hours **in its own timezone**, because the hours are copied into the schedule as wall-clock times. Picking support hours from another timezone is refused, and the error names both zones; the picker labels them with their timezone, as in **Night shift · America/New\_York**. For the same reason, a support hour's timezone cannot be changed while a schedule in another timezone follows it. {% endhint %} ### Where a support hour is used The support hour's page lists what references it under **Used in**, grouped into **Alert sources**, **Schedules**, **Call flows** and **Event flows**, each with the number of entries and a **Show all** link when the group is longer than the page shows. An event flow counts whether it branches on the support hour in a **Support hours** node or holds for it in a **Wait** node. Those are also the references that block a delete. The error names what is in the way — for example *Cannot delete these support hours, as they are used in alert sources (Production API) and schedules (EMEA primary), please remove them first.* Remove them, then delete the support hours. {% hint style="info" %} **One kind of reference is not counted.** Support hours named in an [ICL](/developer-docs/icl-ilert-condition-language.md) condition, such as an alert source's event filter, are not listed under **Used in** and do not stop a delete. Check your conditions before deleting support hours that are used in one. {% endhint %} --- # 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/alerting/configure-alerting/support-hours.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.