> ## Documentation Index > Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt > Use this file to discover all available pages before exploring further. # On-call and escalation > Build on-call schedules with rotations and temporary coverage, and escalation policies that page the right person and move on when nobody answers. An escalation policy decides who is paged for an incident, and in which order. Its steps can name people, teams, or on-call schedules, so the page follows the rotation instead of a fixed person. Open **Alerts → On-call schedules** and **Alerts → Escalations**. Reading them requires `schedules.read` and `alerts.read`; changing schedules requires `schedules.manage`, and changing policies requires `alerts.manage`. ## How a page reaches someone 1. A rule fires and opens an incident. The incident uses the escalation policy of the rule. 2. Step 1 of the policy runs: each target receives a notification event. A user target is that person, a schedule target is whoever is on call now, and a team target goes to the team as a whole. 3. [Notify policies](https://docs.molesignal.com/en-US/notification-channels#create-templates-and-policies) turn each event into deliveries: the connectors, the personal order of each person, and the fallback routes. 4. When nobody acknowledges within the **Ack timeout** of the step, the next step runs, until the incident is acknowledged or resolved, or the steps run out. A silence that matches the incident stops the escalation while it lasts. With several `alert` nodes, each rule belongs to one node, and that node also escalates the incidents of the rule. See [Role-based deployment](https://docs.molesignal.com/en-US/deployment/role-based.md#work-division-between-alert-nodes). ## On-call schedules **On-call schedules** lists the schedules with their timezone, rotations, people, who is on call now, the next handoff, and the state. The head sums up the schedules, the people on call now, the handoffs this week, and the temporary coverage. Filter by schedule, team, owner, timezone, or state, or show **Only schedules I participate in**. | State | Meaning | | - | - | | **Active** | Someone is on call. | | **Handoff soon** | The next handoff is within 2 hours. | | **Not started** | The first rotation has not begun. | | **Paused** | The schedule is paused and puts nobody on call. | | **Coverage gap** | Nobody is on call now. | ### Create a schedule 1. Select **New schedule**. 2. Under **Basic information**, enter the **Schedule name**, a **Description**, the **Timezone**, such as `Asia/Shanghai`, and the **Team**. 3. Under **Rotation rules**, set up each rotation: | Field | Use | | - | - | | Rotation name | For example `primary`. | | **Rotation cadence** | **Daily**, **Weekly**, **Workdays** (daily, Monday to Friday), or **Custom period** with a **Period (hours)**. | | **Start date and time**, **Handoff time** | When the rotation begins, and the time of day the shift changes. | | **Members (rotate in order)** | The people, in the order they take turns. | | **Restrict to specific days / hours** | Covers only some weekdays, between **Hour start** and **Hour end**, in the timezone of the schedule. | 4. Check **Next 7 days**, which previews the order, the handoff times, and the people covered. 5. Select **Create schedule**, or **Save draft** to keep it paused. When several rotations cover the same moment, the first one in the list that has someone on call decides. Add a second rotation, for example for nights or weekends, below the first. ### Temporary coverage A temporary override hands on-call to one person for a fixed window, for leave, a swap, or an incident. On the schedule, select **Add override**, choose the **Covering person**, enter the **Reason**, the **Start time**, and the **End time**, and save. An override wins over every rotation while it lasts. Two overrides of one schedule cannot overlap. The form warns when the person is on call for another schedule at the start, and when the start is already past, which makes the override active at once. **End coverage** ends a running override early. ### Schedule details and actions Open a schedule to see who is on call now and since when, the next handoff, the rotation rules, the temporary coverage, a **Next 7 days** timeline, and the **Change history** of the schedule. The menu of a schedule has: | Action | Effect | | - | - | | **Edit schedule** | Changes the schedule and its rotations. | | **Add temporary coverage** | Adds an override. | | **Pause schedule** / **Resume schedule** | A paused schedule puts nobody on call, so steps that target it reach nobody. | | **Copy schedule** | Creates a copy named ` copy`. | | **Export calendar** | Downloads the shifts as an `.ics` file for a calendar. | | **Delete schedule** | Deletes it. | [Home](https://docs.molesignal.com/en-US/home.md#on-call-activity-and-dashboards) shows the current shift, and members choose how on-call events reach them in [Account settings](https://docs.molesignal.com/en-US/account.md#notify). ## Escalation policies **Escalations** lists the policies with who is told, and when. 1. Select **New policy** and enter the **Policy name**. 2. For each step, choose **Applies from severity** (**Any severity**, or a minimum severity), the **Ack timeout** (1, 5, 10, 15, or 30 minutes, or 1 hour), and the **Targets**: a **User**, a **Schedule**, or a **Team**. **Add step** adds the next step. 3. Optionally turn on **Repeat the whole policy until acknowledged**, with **Max loops**. 4. Select **Create policy**. A step whose minimum severity is higher than the severity of the incident is skipped. The connectors and the fallback routes of each delivery are set in **Settings → Notify → Policies**, not in the escalation policy. ### The default policy A rule names its escalation policy with `escalation_policy_id`. A rule that names none, as every rule saved in the rule workbench, uses the alias `default`: the policy of the organization named `default`, without regard to case. Without such a policy, its incidents escalate to nobody. Create a policy named `default` before the first rule, for example with the primary on-call schedule in step 1 and the team lead in step 2. Once an incident has started escalating, it keeps the policy it found, even if the `default` policy is renamed later. ## API | Operation | Endpoint | | - | - | | Create an escalation policy | [`POST /api/v1/alerts/escalations`](https://docs.molesignal.com/en-US/api/alerting/create-escalation) | | Point a rule at a policy | `escalation_policy_id` in [Create a rule](https://docs.molesignal.com/en-US/api/alerting/create-rule.md) | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.