-
Notifications
You must be signed in to change notification settings - Fork 0
Concepts On Call Schedules
An On-Call Schedule defines who is responsible for responding to incidents at any given time. Instead of sending every alert to a fixed set of recipients, schedules let you rotate that responsibility across your team — so the right person is notified depending on the time of day, day of the week, or any custom recurrence pattern you define.
Schedules are used by Escalation Policies to determine who to notify at each step of an escalation.
| Field | Description |
|---|---|
| Name | A short label for the schedule (e.g. "Backend On-Call", "Weekend Rotation") |
| Description | Optional free-text notes about the schedule's purpose |
| Timezone | IANA timezone identifier (e.g. America/New_York, Europe/Madrid). Used for display — all times are stored in UTC internally |
| Notify on shift start | When enabled, the incoming on-call user receives a notification at the start of their shift |
| Starts at / Ends at | Optional date range bounding the schedule's active window. Leave blank for a schedule that runs indefinitely |
A schedule is made up of one or more layers. Each layer defines a recurring coverage window and the users who rotate through it.
| Layer field | Description |
|---|---|
| Name | Label for the layer (e.g. "Weekday coverage", "Weekend") |
| Order | Display order within the schedule. Lower numbers appear first |
| First occurrence start / end | The start and end times of the first shift. The duration of every subsequent shift is derived from this interval |
| Recurrence rule | An iCalendar RRULE string describing how the shift repeats (e.g. FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR for weekdays) |
| Members | The users who rotate through this layer, in order |
Piro evaluates the recurrence rule starting from the first occurrence to generate all future shift windows. Users in the layer rotate through those windows in the order listed — user 1 takes the first window, user 2 takes the second, and so on. When the list is exhausted it wraps back to the beginning.
If multiple layers are active at the same time, all of them contribute on-call users — the schedule's final on-call set is the union of every active layer's current user.
An override lets you substitute coverage for a specific time window without changing the underlying rotation. Use cases include swapping shifts for a holiday or covering a sick colleague.
An override can either:
- Replace a specific user during the window (that user is removed; the override user takes their place)
- Add coverage without replacing anyone (useful for supplemental on-call during high-risk deployments)
An optional reason field lets you document why the override was created.
Admin panel → On-Call → Schedules
From there you can create and edit schedules, manage layers, and add or remove overrides.
- Use a separate layer per coverage window type (e.g. business hours vs. after-hours) rather than trying to encode everything in a single complex RRULE.
- Set Notify on shift start so on-call users always know when their shift begins — especially useful for schedules that rotate frequently.
- Use overrides for planned absences. Editing the rotation itself to handle one-off changes makes the schedule harder to maintain long-term.
- The timezone field affects display only. If your team is distributed, pick the timezone most of the team operates in for readability.
- Escalation Policies — policies reference schedules to determine who to notify at each escalation step
- Triggers — alert channels that can be used alongside on-call routing