Skip to main content
RunBook Academy

Git, CI/CD & GitOpsLVII · Approval GatesWhenApprovalHelps

When approval adds safety — the scenarios where a human checkpoint prevents real incidents

Intermediate⏱ ~19 mingit

What you'll learn

  • Identify the three categories of production failure that automated checks cannot catch
  • Recognise the production-context, timing, and risk-tolerance decisions that require human judgement
  • Distinguish a safety gate from a checkbox gate using latency, rejection rate, and audit context
  • Apply the diagnostic signals to evaluate whether an existing approval rule is safety or ceremony

Prerequisites

Verified against Git 2.55.x teaching target; 2.40+ minimum · GitHub Actions continuous service; Aug 2026 documentation baseline · Argo CD v3.5.x teaching target; v3.0+ minimum · Flux v2.9.x · Sigstore Cosign v3.1.x · SLSA v1.2 · OCI Distribution Specification v1.1 · Git LFS v3.7.1 · Kubernetes (cross-course target) 1.36.x

Not yet marked complete on this device.

An approval gate is not safety in itself. The gate is safety when it catches a category of failure that automated verification cannot. Three categories exist: production-context, timing, and risk tolerance. Each requires a human reading the change in the moment the deploy is requested, not a CI check that ran against the diff an hour earlier. This lesson identifies those categories; LVII-02 covers the cases where the same mechanism adds only friction.

What automated checks miss

A green CI run, a passing test suite, and a reviewed pull request are necessary preconditions. They are not sufficient. They answer does this change work in isolation? but not the questions that matter at the production boundary:

  • Production-context. A migration that runs cleanly against an empty table can corrupt a table that already holds a million rows. A feature flag flipped off in staging can collide with a flag flipped on by an unrelated deploy five minutes earlier.
  • Timing. Is now the right moment? An incident is being mitigated, a migration is in progress, the on-call rotation is empty because of a public holiday. A CI check at PR time cannot answer these because they are properties of the present.
  • Risk tolerance. A 5% error-rate spike is acceptable in a canary; it is not acceptable in a global rollout.
flowchart TD
    A["Deploy requested"] --> B{"Production-context safe?"}
    B -- "no" --> Z["Hold"]
    B -- "yes" --> C{"Timing right?"}
    C -- "no" --> Z
    C -- "yes" --> D{"Risk acceptable?"}
    D -- "no" --> Z
    D -- "yes" --> E["Approve and deploy"]

A human approver reading the change in context is the only mechanism that catches all three.

Five scenarios where approval changes the outcome

  1. Database migrations. A migration that passes CI on an empty test table can acquire a long lock on a production table with millions of rows. A reviewer reading the migration in context catches the production-scale failure.
  2. Feature-flag flips. A flag flipped off in staging can collide with a flag flipped on by an unrelated deploy.
  3. Dependency upgrades. A library upgrade that passes CI can introduce a runtime regression under production load or against a production-only code path.
  4. Schema or contract changes. A breaking change to an API, database schema, or message contract can pass all automated tests and still break a downstream consumer that is not in the CI test set.
  5. Security-sensitive changes. IAM policies, network rules, secrets handling, and audit logging - consequences here are measured in regulatory exposure, not uptime.

Diagnostic signals for a real gate

Three signals distinguish a safety gate from a checkbox:

  • Latency. A real gate adds seconds to minutes between artifact-ready and deploy-running.
  • Rejection rate. A real gate occasionally rejects. Zero rejections over six months is a checkbox.
  • Context in the audit trail. A real gate records why the change was approved, not only that it was.

A gate with low latency, zero rejections, and no recorded reasons is a gate that exists in configuration but is not exercised.

Production discipline

  1. The gate is safety when it catches a category of failure automated checks cannot. Production-context, timing, and risk tolerance are the categories.
  2. Audit the gate’s latency and rejection rate. A gate that approves in milliseconds is a rubber stamp.
  3. Require reviewers to record a reason. A comment on approval captures the decision in the audit trail.
  4. Expand the reviewer pool. A single approver who rubber-stamps every change is a single point of failure.

Cross-course references

  • This course, Part LV-03 (Continuous delivery) covers the gate as the structure that distinguishes delivery from deployment.
  • This course, Part LVII-02 (When approval adds bureaucracy) covers the scenarios where the same gate adds friction without adding safety.
  • Linux for Production Sysadmins - Part XXII (ChangeMgmt) covers the change-management discipline that historically implemented the gate.

Quiz

Knowledge check · 4 questions

  1. Q1. A migration passes all CI checks against an empty test database. The table in production has accumulated two million rows. The migration acquires a lock that blocks writes for four minutes. Which category of failure does a human approver catch that CI did not?

  2. Q2. An approval gate that approves every deploy within five seconds and has rejected zero deploys in six months is functioning as a safety gate.

  3. Q3. Name the three categories of production failure that automated checks cannot catch and that a human approval gate exists to catch.

  4. Q4. Diagnose why a sequence of database migrations passed CI and a code review but still caused an incident, and identify what gate behaviour should have caught the failure.

    A team merges three migrations in sequence. Each passes CI against a test database. The code reviewer approves all three. The deploy is gated by a single required reviewer who approves within seconds. The migrations run in production in sequence. The first succeeds. The second acquires a lock that blocks writes for two minutes; the team pages itself when customers begin to see errors. The third is held automatically by the platform because the second is still running. The incident postmortem finds that the second migration was the problem; the lock was unexpected because the team's test database never had the volume that production had.

Passing score: 75%. Answers are checked in this browser.