Engineers App

On-Call Schedule

Who's on shift right now, when your next handoff is, and how the rotation works — read-only on the mobile app, admin-managed in the dashboard.

The Schedule tab#

The Schedule tab shows live on-call data for your project — pulled from GET /api/v1/mobile/oncall on open and refreshable via the pull-to-refresh gesture.

The hero card#

The big card at the top adapts to your situation:

  • You are on-call — blue hero, "YOU ARE ON CALL" badge, live countdown to your shift end, progress bar, name of who takes over next.
  • Someone else is on-call — indigo hero, "ON CALL NOW" badge, their name and shift window.
  • Nobody is on-call — neutral card explaining that incidents will still page the full audience as a fallback. Most common cause: schedules disabled at the project level or no shifts entered yet.

Sections below the hero#

  • On call now — one card per currently-rostered engineer across all active schedules (multiple schedules can overlap). Your card has a brand-blue highlight border.
  • Up next — the next 5 upcoming shifts across all active schedules. Your shifts get a "YOU" pill. Friendly weekday + time labels ("Mon 9:00 AM - 5:00 PM").

How the rotation is decided#

The mobile app is read-only for rotation. Schedules, shifts, overrides, and the rotation pattern itself are all configured by an admin in the web dashboard at On-Call → Schedules. Engineers don't self-assign themselves to shifts; the schedule generator does it.

Why read-only?

Letting engineers edit their own shifts would let one person quietly trade themselves out of weekend coverage. The audit trail also matters for compliance — a schedule is a contract, not a personal calendar. Coverage swaps go through the request flow (see below) so they leave a paper trail.

Quick actions (coming soon)#

Three buttons sit under the hero — all currently disabled with a "Coming soon" toast:

  • Swap — request to trade shifts with another engineer. The other engineer accepts/declines in their app; on accept, the system writes an oncall_overrides row for each side of the swap.
  • Cover — request someone to cover a specific shift for you. Same flow as Swap but one-directional.
  • Remind — schedule a reminder before your next shift starts.

For now, all rotation changes go through your admin. If you need a swap urgently, ping them on Slack and they'll create an override from the dashboard — that takes about 30 seconds.

Schedule vs paging — what actually decides who gets paged#

The schedule is a filter, not the audience. The audience is decided by tier (or policy steps); the schedule narrows it to whoever is rostered right now. There's also a severity bypass that ignores the schedule entirely for SEV1s.

SettingEffect
Schedules disabledEvery incident pages the full tier/policy audience. Mobile schedule tab shows the fallback hero.
Schedules enabled, on-call existsIncident filters to whoever's rostered.
Schedules enabled, no roster gapSafety fallback — page the full audience anyway. Alert isn't dropped just because the schedule is empty.
Severity ≥ bypass threshold (default critical)Ignore the schedule entirely. Page everyone.

Practical takeaway

Even if you're not on shift, you can still be paged on critical incidents. The schedule layer narrows non-critical paging to the on-call engineers; severe stuff still wakes everyone. Treat the schedule as a noise filter, not an opt-out.

For the admin-side view of how schedules + rotations are set up, see the dashboard at /dashboard/on-call.