OnCallRadar is a roster with a pull-request-style approval workflow — not a paging or alerting tool. These are the concepts everything else builds on.

Schedule

A schedule is one on-call rotation with its own participants, approvers, coverage rules, and an optional escalation chain. Each schedule carries its own access list, independent of the others.

Shift & rotation

A shift is one person on call for a span of time. A rotation is a repeating pattern that generates shifts forward over a horizon. Time is stored in UTC and snapped to the organization’s minimum slot (default 60 minutes); it is displayed in each viewer’s own timezone.

Proposal & approval

The published roster is the only thing viewers read, and unapproved edits never touch it. When you edit a calendar you create a proposal holding your changes. Approvers open it and see a diff: the current published calendar versus the projected result, plus each approver’s decision and any flags on the projected state.

• Quorum — a proposal applies once it has as many approvals as the schedule’s *required approvals*.
• Conflict on apply — if the published schedule changed underneath the proposal, applying fails with “schedule changed — recreate”. There is no auto-merge or rebase.
• Self-approval — your own approval only counts toward quorum if you hold the *Approve own changes* permission.

Flags (advisory)

Flags surface overlaps (two people at once, if the schedule flags overlaps) and gaps (nobody on call, if the schedule requires 24/7 coverage). Flags are advisory — they never block saving or approving. Overlap is a permitted, intentional state; a gap is a valid state too, rendered explicitly rather than treated as an error.

Change log

Every applied change and every approval decision is written to an immutable change log — who did what, and when. Because the roster is shared with no single owner, that log is the accountability backbone.