On-Call

On-Call scheduling lets your team define who is responsible for after-hours and out-of-coverage support, page the right person when something needs attention, and keep an auditable record of every change.

Overview

The On-Call module lets you:

• See who is on-call right now and when the next handoff happens
• Build repeating rotations that drive the base schedule
• Generate concrete schedule shifts from a rotation for any date range
• Swap a specific shift with an override, or add a one-off exception for ad-hoc coverage outside a rotation
• Define escalation policies that page additional members in steps when an alert goes unacknowledged
• Review alert history and acknowledge, resolve, or silence alerts
• Manage holidays and closures that affect coverage
• Audit every on-call change in the Activity trail

Navigate to On-Call

Open the On-Call item under the Team Management section of the left sidebar (/on-call).

Sections

The page is organized into tabs across the top:

Tab	What it shows
Overview	Active alert banner, the "On-Call Now" widget, and the schedule calendar
Rotations	Create, edit, and delete rotations, and generate schedule entries
Escalation	Build escalation policies with ordered notification steps
Alert History	Past and active alerts with acknowledge/resolve actions
Holidays & Closures	Federal holidays and custom org closures that affect coverage
Activity	Audit trail of all on-call changes

The scheduling model

On-call scheduling is built around three concepts:

• Rotation — the repeating base schedule. A rotation cycles through an ordered list of members.
• Override — a one-time swap that hands a specific generated shift to a different member.
• Exception — ad-hoc, one-off coverage outside any rotation (for example, a gap fill or holiday backup).

Overview tab

The Overview tab opens to a snapshot of current coverage:

• Active alert banner — appears at the top when there is an unacknowledged alert, with a link to view its detail.
• On-Call Now widget — shows the member currently on-call. When more than one coverage layer is active it lists the Primary member first, then each Backup. If no one is scheduled, it reads No one on-call.
• Schedule calendar — a Week or Month view of generated shifts, overrides, and exceptions, color-coded per team member. Use the < / Today / > controls to move between periods. A Gap marker highlights days that are not fully covered.
• Print — produces a printable view of the visible schedule.

Members with the override permission also see a Configuration panel with quick links to Manage Rotations, Escalation Policies, and Alert History, plus an Add Exception button.

Add an exception

1. Click Add Exception (or the + on a calendar day).
2. In the Add Schedule Exception dialog, choose the member, set the start and end date/time, and optionally add a note.
3. Save. The exception appears on the calendar as one-off coverage.

Create an override (swap a shift)

1. Click a rotation-generated shift in the calendar.
2. Select the covering member, optionally add a reason, and confirm the time window.
3. Save. The override replaces the original member for that shift. You can cancel an override later from the same shift.

Time off and on-call coverage

When a member requests time off that overlaps a shift they are on call for, the time-off approver is warned, and an approval that would leave the shift with no other coverage is blocked until acknowledged. Creating an override (above) for the affected window is the recommended way to resolve the gap before approving. See Schedule → On-call coverage gate.

Request a shift swap

An override is a manager/admin action applied directly to a shift. A shift swap request is the peer-initiated version: you ask a teammate to cover (or trade) one of your own shifts, and the swap only takes effect once they accept.

1. Open one of your upcoming shifts and choose Request swap.
2. Pick the teammate you want to cover it. Optionally narrow the window to part of the shift, add a note, and — for a true trade — pick one of their shifts to cover in return.
3. Send the request. The teammate gets a notification and an action-required item in their inbox asking them to accept or decline.
   • Accept → an override is created automatically so the coverage updates immediately (two overrides for a trade), and you're notified.
   • Decline → you're notified and the shift is unchanged.
   • You can cancel a request you sent while it's still pending.
4. If the teammate is already on call during the window, an advisory warning is shown (the swap is still allowed — it's a heads-up, not a block).

Pending requests expire automatically once the shift begins. Requesting and responding to swaps requires the swap request permission on the on-call schedule (granted to all members for their own shifts by default).

Rotations tab

Rotations define the base repeating schedule.

1. Click New Rotation (or Create Rotation when none exist yet).
2. Fill in the rotation details:

Field	Description
Name	The rotation name (required) — e.g. "Tier 1 On-Call"
Description	Optional notes
Rotation Type	Weekly (7-day shifts) or Custom (1-day shifts)
Coverage Layer	Which coverage tier this rotation provides — Primary, Backup, or a deeper layer (see Schedule layers below)
Handoff Time	Local time of day the rotation hands off (e.g. 09:00)
Timezone	The timezone the handoff time is interpreted in
Members (rotation order)	The ordered list of members the rotation cycles through; reorder with the up/down controls

3. Save the rotation. Each rotation shows an Active / Inactive badge, a Primary / Backup layer badge, and its handoff time and timezone.

Schedule layers (primary & backup coverage)

A rotation runs on a coverage layer, so you can stack several rotations that are on-call at the same time instead of being limited to one person:

• Primary (Layer 1) — the first responder. This is the default for every rotation, so existing single-rotation setups are unchanged.
• Backup (Layer 2) and deeper layers (Layer 3, Layer 4, …) — run concurrently behind the primary as secondary coverage.

To run primary + backup coverage, create two rotations for the same window — one on the Primary layer and one on the Backup layer — each with its own members and rotation cadence, and Generate Schedule for both.

Coverage is always resolved primary-first:

• The On-Call Now widget lists the primary member first, then each backup with its layer badge.
• The schedule calendar tags backup shifts with a small Backup / L3 marker so layered coverage is visible at a glance.
• Ticket notifications and alert routing page the primary layer; lower layers are surfaced as additional coverage.

Generate schedule entries

A rotation is just a definition until you generate concrete shifts from it:

1. On a rotation, click Generate Schedule.
2. Choose a Start Date and End Date.
3. Click Preview Schedule to see the shifts that would be created.
4. Click Save Schedule to write the generated entries to the calendar.

Generated shifts then appear in the Overview calendar and can be overridden individually.

Escalation tab

Escalation policies decide who gets paged, and when, if an alert is not acknowledged.

1. Give the policy a Policy Name.
2. The first step (Step 1) is always notified immediately when the alert triggers — choose its Notify members.
3. Click Add Escalation Step to add later steps. For each additional step, set:
   • Escalate after (minutes) — how long to wait, measured from when the alert was triggered, before this step fires.
   • Notify members — the members paged at this step.

When an alert with an attached policy stays in the Triggered state, a recurring background check advances through the steps whose delay has elapsed and notifies each step's members. By default, notifications are delivered both in-app and by email according to each recipient's notification preferences.

Per-step delivery rules

Each step can be tuned beyond "page these members" so a policy can match how your team actually wants to be reached (PagerDuty-style notification rules):

• Channels — choose any combination of In-app, Email, and Webhook for the step. When you set channels explicitly, they are honored even if a recipient has turned that notification type off in their preferences — an escalation page is not something you opt out of per step. (The member-level Receive notifications toggle and disabled accounts are always respected.) A step left without an explicit channel selection keeps the default in-app + email behavior governed by each recipient's preferences.
• Webhook recipients — when a step includes the Webhook channel, pick one or more of your configured outbound webhooks. Each fires through the same signed, retried delivery pipeline as your other webhook events (event type oncall.escalated), so you can route a page to a chat tool (for example, a Slack-compatible receiver) or any custom endpoint without a separate integration. The delivered payload includes the alert id, what triggered it, the step number, and a ready-to-render message/text.
• Notify until acknowledged — turn this on for a step to keep re-paging it on a cadence you set (Repeat every N minutes) until the alert is acknowledged or the next step becomes due. This prevents a missed page from going unnoticed while still respecting that an acknowledgement stops all further paging.

A step must page at least one member or one webhook, and a "notify until acknowledged" step must specify its repeat interval.

Alert History tab

The Alert History tab lists alerts and lets you act on them.

• Filter by status using the dropdown: All statuses, Triggered, Acknowledged, Resolved, or Silenced.
• Click Refresh to reload.
• Click an alert to open its detail view, where you can Acknowledge, Resolve, or Silence it.

Alert statuses:

Status	Meaning
Triggered	The alert is active and escalating
Acknowledged	Someone has taken ownership; escalation stops
Resolved	The alert is closed
Silenced	Escalation is paused for a chosen number of minutes, after which the alert automatically returns to Triggered

When you silence an alert you choose a duration in minutes (the default is 60). Once that window expires, the alert is flipped back to Triggered so escalation resumes.

How on-call ties into tickets

When a new ticket is created while on-call coverage is active, the member currently on-call is notified ("On-Call: New Ticket #…"). Ascent uses the same coverage resolver everywhere — the On-Call Now widget, ticket notifications, and alert routing all agree on who is on-call at a given moment. When primary and backup layers overlap, the primary member is the one paged. Coverage is considered active based on your SLA business hours combined with weekend, holiday, and closure rules.

Shift-starting reminders

Whoever is up next on call gets an automatic reminder shortly before their shift begins, so a handoff is never a surprise. The reminder arrives in-app and by email according to the recipient's notification preferences and links to the On-Call overview; it is sent at most once per shift. Members can turn it off under the On-Call category on Profile → Notifications.

Holidays & Closures tab

This tab manages the dates that affect coverage:

• Federal holidays — toggle and rename the standard set of holidays per org.
• Org closures — create custom closure records for your organization.

These dates feed into coverage calculations so the right person is on-call during days your office is closed.

Activity tab

The Activity tab is an audit trail of every on-call operation. Filter by entity type:

• Rotations
• Overrides
• Schedule Entries
• Escalation Policies
• Alerts
• Coverage Rules
• Holiday / Closures

Each row records the action, the user, and a timestamp. Results are paginated.

Permissions

On-call capabilities are governed by RBAC across four resources:

Resource	Typical actions
On-Call Rotations (on_call_rotations)	Create, read, update, delete, generate
On-Call Schedule (on_call_schedule)	Read, override, swap request
On-Call Escalation Policies (on_call_escalation_policies)	Create, read, update, delete
On-Call Alerts (on_call_alerts)	Create, read, acknowledge, resolve, silence

Schedule-changing controls (adding exceptions, creating overrides) require the override permission on the on-call schedule, which is granted to Owners and Admins by default but can be delegated through Roles & Permissions. Peer shift swap requests use the separate swap request permission, granted to all members by default so they can request and respond to swaps for their own shifts (the API still enforces that only the requestor or target can act). The Activity audit trail requires read access to on-call rotations.

Tips

• Build a rotation first, then Generate Schedule for the period you want covered — overrides and exceptions are easiest to apply on top of generated shifts.
• Watch for the Gap marker on the calendar; it flags days where coverage is incomplete.
• Attach an escalation policy to alerts so an unacknowledged page reaches the next person automatically instead of sitting idle.
• Subscribe to your on-call shifts from your own calendar app: the Calendar subscription feed can include your on-call shifts (and approved time off) as a live, revocable iCal feed — handy for seeing your next shift alongside the rest of your day.