On-call and escalations

Governance isn't just about paperwork after the fact - it's also about making sure that when something actually goes wrong, a specific, accountable human finds out, instead of an alert quietly expiring unread. On-call rotations and escalation ladders are the mechanism: this page explains the concepts and, specifically, how automated triggers - not a person noticing something and manually raising an alarm - end up reaching a human being.

Both live on Admin -> SLA & escalation, alongside SLA (response-time) policies. For the complete field-by-field setup walkthrough - building a schedule, building a ladder tier by tier, every option and its effect - see Alerts and SLA; this page focuses on the concepts and the governance angle: accountability, and how a machine-detected problem finds its way to a person.

On-call, from zero

On-call means: at any given moment, exactly one person is designated as responsible for responding if something needs a human right now. An on-call rotation automates who that is over time - a round-robin list of people who hand the responsibility to the next person on a schedule (say, weekly), so responsibility for "who gets paged at 3am" is a standing, known answer rather than something decided ad hoc every time an incident happens.

This matters for governance specifically because it converts "someone should probably notice this eventually" into a named, accountable person at every point in time - which is exactly the kind of thing an auditor, or your own leadership, will ask to see evidence of.

Escalation ladders, from zero

An escalation ladder is an ordered chain of response tiers: tier 0 notifies someone immediately; if nobody acknowledges within that tier's configured delay, tier 1 fires; if that's also unacknowledged after its own delay, tier 2 fires, and so on. Each tier's target can be a specific fixed person, everyone holding a given project role, or - tying back to the previous section - whoever the on-call rotation says is currently on duty.

The point of a ladder is resilience against a single point of failure: if the first person notified is asleep, on vacation, or simply misses the notification, the problem doesn't just sit unacknowledged - it climbs to the next tier automatically until someone acknowledges it.

How agent and system triggers reach a human

This is the part that's specific to a workspace where a meaningful share of the work - and the monitoring of that work - is automated. orboto's alert rules watch for conditions nobody has to notice by hand: a budget crossing a threshold, a ticket sitting stuck in one status too long, a milestone's AI-generated risk assessment flipping to red, a sprint gone quiet with no activity. None of these require a person to be watching - they're evaluated automatically, either the instant the triggering change happens or on a recurring schedule, and several of them are themselves the product of orboto's own AI analysis (the AI risk assessment trigger being the clearest example: an automated judgment about a milestone, not a human opinion).

An SLA breach - a ticket's response or resolution timer running out - is the same story from a different angle: it's the system detecting that a commitment is at risk, not a person who happened to check.

Both of these - a fired alert, and an SLA breach - can be wired to an escalation ladder so the automated detection doesn't stop at "a notification was sent and might get read eventually." Once wired, the ladder guarantees the chain above: tier 0 fires, and if nobody acknowledges, it keeps climbing until it reaches someone who does. This is the concrete answer to "how does an agent or an automated check actually get a human's attention" - it's not a side channel or a hope that someone reads a notification feed; it's the same escalation machinery either way, whether the thing that noticed the problem was a person, an alert rule, or an AI risk assessment.

The governance record

Every escalation instance - a live, in-progress climb up a ladder - has a status (active, acknowledged, resolved, or exhausted if every tier fired with no response) and, crucially, is recorded: who acknowledged it and when. Combined with the on-call schedule's own history of who was on duty at any given moment, this is what lets you answer "who was responsible when this happened, and did they respond" after the fact - not just "we have an on-call rotation" as a policy statement, but a factual record of it functioning (or not) for any specific incident.

Setting it up

The step-by-step for both surfaces - creating an on-call schedule, adding members, setting a rotation length and hand-off time; building a ladder tier by tier with delays and targets; wiring an SLA policy to a ladder - lives in Alerts and SLA. This page intentionally doesn't repeat those steps; come here for the concept and the governance framing, go there to actually build one.

Permissions

Reading on-call schedules requires admin:oncall:read; reading escalation policies and their running instances requires admin:escalation:read. Managing schedules, members, and overrides requires admin:oncall:write; managing ladders and acknowledging a running instance both require admin:escalation:write (acknowledging changes escalation state, so it needs the write permission even though it isn't editing the policy itself). Every mutation on either surface is audit-logged.

Troubleshooting

For symptom-level troubleshooting (a rule that never fires, a timer that shows breached with no notification, an on-call tier resolving to the wrong person), see the Troubleshooting section of Alerts and SLA - it covers both surfaces in depth since the day-to-day debugging is identical regardless of which admin section you read the concept from.

One governance-specific point worth calling out here: an escalation instance's audit trail is only as good as someone actually acknowledging it. A ladder that fires and exhausts every tier with no acknowledgment still leaves a complete record that nobody responded - which is exactly the situation a periodic governance review should be checking for, not something to notice only when an auditor asks.