Approval fatigue and bypass risks — the failure mode and the warning signs

LVII-01 covered what makes an approval gate substantive; LVII-02 covered when the gate becomes ceremony; this lesson covers the failure mode that emerges when the gate has been ceremony for long enough to be ignored entirely. Approval fatigue is the human behaviour of approving changes without reading them; the fatigue produces bypass behaviour; the bypass behaviour produces silent failures.

What approval fatigue is

Approval fatigue is the human condition that emerges when a reviewer is asked to approve too many changes, too quickly, with too little context. The reviewer starts by reading each change carefully; the cost accumulates; the reviewer begins to skim; the skimming becomes rubber-stamping; the rubber-stamping becomes the default.

Three properties define the fatigue:

• Volume. Many changes per day.
• Latency pressure. Deploys are time-sensitive.
• Lack of consequence. Approved changes rarely cause incidents; no feedback loop.

flowchart LR
    A["High volume"] --> B["Skim instead of read"]
    B --> C["Rubber-stamp"]
    C --> D["No consequences"]
    D --> E["Rubber-stamp is the default"]
    E --> F["Bypass pressure grows"]
    F --> G["Verbal nod for hotfixes"]
    G --> H["Silent bypass"]

Each step is small; the sequence is large.

Five warning signs

Five signals indicate the gate has crossed into fatigue:

• Approval latency under ten seconds for every deploy.
• Same approver for every deploy over a week.
• Zero rejection comments over three months.
• Hotfixes that bypass the gate with manager verbal nod.
• Audit logs that show deploys but no reviewer comments.

A team that audits the log quarterly catches the fatigue before it becomes bypass.

The bypass failure modes

Three bypass failure modes emerge:

• Verbal-nod hotfixes. A senior engineer approves a deploy verbally, outside the platform. The audit records the deploy but not the verbal approval.
• Admin override. A repository administrator uses bypass authority to push or skip the rule. The override is logged but treated as normal.
• Shadow approval process. Email or Slack carries the actual approval. The platform gate is satisfied with a token approval from someone who already approved in the channel.

The platform record shows the gate was satisfied; the actual gate was bypassed. The record is honest; the gate is fiction.

Detecting bypass

Three detection mechanisms:

• Latency monitoring. Track time between deploy request and approval. Latencies under ten seconds are a smoking gun.
• Comment-rate monitoring. Track the rate at which approvals carry a comment. A team that never comments is not reading.
• Rejection-rate monitoring. Track the rate at which approvals are rejected. Zero rejections in three months is not exercising the gate.

The three metrics catch the fatigue before it becomes bypass.

The discipline of removing a bypassed gate

A gate that has been bypassed silently has stopped functioning. The discipline is to remove it.

The protocol:

1. Audit the gate. Latency, rejection rate, comment rate.
2. Decide. Tighten or delete.
3. If tightening: change the configuration; require comments; set a wait timer; expand the pool.
4. If deleting: remove the rule; document the removal.
5. Audit past deploys. Preserve as evidence.

The protocol closes the gap forward.

Production discipline

1. Audit the gate quarterly. Latency, rejection rate, comment rate.
2. Treat zero rejections over three months as a warning.
3. Treat zero comments over three months as a warning.
4. Treat verbal-nod hotfixes as bypass evidence.
5. Remove bypassed gates. Delete the rule.

Cross-course references

• This course, Part LVII-02 (When approval adds bureaucracy) covers the ceremony side of the failure.
• This course, Part LVII-01 (When approval adds safety) covers the substantive side.
• This course, Part XLVI-04 (Observability and SLOs) covers the metric-driven discipline.

Quiz