Approval Escalation is the time-boxed chain behind every approval in Approval Queue. Each tier has a TTL. If the tier does not respond in time, the request escalates to the next tier automatically. The chain is configurable per service tier and per action class. No more "we paged the on-call but they were on a flight, so the action just sat there for two hours."
The default chain has five tiers. The action's owner team is tier 1. Their on-call is tier 2. Team lead is tier 3. Secondary on-call is tier 4. Platform admin is tier 5. Each tier has its own TTL: short for low-risk classes, longer for time-sensitive incidents. Tiers can be added, removed, or reordered per action class.
A routine config change can wait an hour. A destructive prod operation cannot. Each action class has its own escalation chain. Routine: 60-minute TTL per tier. Destructive (DROP, TRUNCATE, force-push): 2-minute TTL with simultaneous notify to all five tiers. The class-specific tuning is what makes the system feel calibrated, not annoying.
Each engineer can mark quiet hours (vacation, parental leave, conference). The chain skips quiet-hour engineers and goes to the next available tier. The skip is logged so audit can see why a request escalated faster than usual. Nobody gets paged at 3am when they marked themselves unreachable.
If every tier exhausts without an approval, the request does NOT escalate to "just do it anyway." The agent falls back to suggest mode and writes a runbook for the next available human to execute by hand. Default-deny is the right posture; auto-approval after a chain timeout would defeat the whole point of the gate.
Subscribe to Nova AI Ops on YouTube for demos, tutorials, and feature deep-dives.
Most approvals land at tier 1. The chain exists for the 5% that do not. Configurable, audited, never silent.