Every team that ships its first remediation runbook does the same thing: it puts an approval gate in front of it. The gate is meant to be a safety rail. Six weeks later the gate is the product — a queue of pending requests, a channel full of thumbs-up emoji, and an automation platform whose primary function is asking a human whether it may please do its job. The failure is almost never the existence of the gate. It is that the gate was built as a pause rather than as a decision surface.
A gate without evidence is just latency
Approvers do not need more time. They need fewer missing facts. Do the arithmetic on your own team: if a reviewer has to open the triggering alert, the runbook definition, the service dashboard and the last execution log before making a call, and each context switch costs roughly 40 seconds of refocusing, you have spent about 2.5 minutes to approve a pod restart. At 25 approvals a day across a platform team, that is an hour of senior attention daily — north of 250 hours a year spent reconstructing context the system already had.
The fix is unglamorous. The approval request should carry the evidence pack inline: the alert that fired and how long ago, the exact plan, the last three executions of this runbook with their outcomes, and the rollback command. Approval then becomes a ten-second read instead of a three-tab investigation. If your approvers are opening a second window to decide, your gate is generating work rather than absorbing it.
Show the plan as a diff, not a paragraph
"Restart the payments-api deployment" and "roll 12 pods, 3 of which sit behind a PodDisruptionBudget with minAvailable 9, expected 4 minutes, rollback in 90 seconds" attract wildly different scrutiny — and wildly different approval speeds. The first invites a question. The second invites a yes.
A runbook planner should render an object-level plan before it ever asks for a signature:
| Field | Value |
|---|---|
| Target | deployment/payments-api |
| Objects changed | 12 pods, 1 deployment revision |
| Availability impact | 3 pods, PDB minAvailable 9 respected |
| Expected duration | 4 min |
| Rollback | kubectl rollout undo, ~90 s |
A six-line table replaces a 200-word description and, more importantly, it replaces the question. The approver is no longer evaluating your prose; they are checking a claim against a constraint they already know.
Blast radius is a number, and it picks the approver
"Low risk" is an adjective, and adjectives cannot be enforced by a policy engine. Every runbook needs to resolve to a tier before the gate renders:
- Auto-execute — one object, reversible in under 60 seconds, no data mutation, no dependency fan-out.
- Single approver — one service, reversible via a tested rollback, contained to a single team's ownership boundary.
- Two approvers plus a change window — irreversible, cross-service, or touching stateful data.
If a runbook cannot be assigned to a tier in 30 seconds of discussion, it is a tier 3. That rule alone prevents most of the arguments that stall rollouts, because it removes the incentive to argue a runbook down a tier in order to avoid a queue.
Bind the approval to the plan, then make it expire
Approvals rot. A plan generated at 09:00 may target a pod set that no longer exists at 14:00, and a signature on the old plan is not consent to the new one. Hash the rendered plan; attach the hash to the approval; regenerate and the approval voids automatically. Then add a default expiry — four hours for tier 2, thirty minutes for tier 3. An approval that has been sitting for eighteen hours is an approval of a world that has since been rebuilt.
This is also the cheapest audit artifact you will ever produce: plan hash, evidence pack, approver identity, timestamp, execution outcome, all in one record that a compliance reviewer can read without asking you anything.
Instrument the gate, because it is a queue
If you would not run a queue without latency metrics, do not run an approval gate without them. The four that matter:
- p50 and p95 approval latency, segmented by tier.
- Approval-to-execution gap, which is where expiry should be doing its job.
- Rejection rate with reason codes, which tells you whether the gate is catching bad plans or bad tooling.
- Rubber-stamp rate: approvals granted in under 15 seconds with no comment, twenty or more times consecutively for the same runbook.
An approval that gets rubber-stamped two hundred times in a row isn't a control — it's an undocumented auto-approve with extra latency.
That last metric is the one teams avoid, because it is the one that tells them a gated runbook has already earned its way out of the gate and nobody filed the paperwork.
The gate is a ladder, not a wall
The direction of travel is not fewer approvals; it is approvals that mean something. Every decision an approver makes — approved, rejected, approved-with-edits — is a labeled example of what your policy engine should have concluded on its own. The mature shape is a system where humans review the tier boundaries and the exceptions, while runbooks that have passed cleanly a few dozen times graduate from two approvers to one, and from one to none, on a schedule rather than on a hunch. The gate stops being where automation goes to wait and becomes the mechanism by which automation earns the right to stop asking.