A security gate override rate is the share of blocked builds or pull requests that someone released anyway. A rate near zero can mean a well tuned gate or one nobody can pass, while a high rate usually means the rule is noisy, unfair or too strict. Read it with the reasons attached.
Definition
Override rate equals overrides divided by gate failures, over a period. Keep the denominator visible. Five overrides out of six failures is a very different story from five out of five hundred.
What different values suggest
| Pattern | Possible meaning | Next step |
|---|---|---|
| Very low, few failures | Gate rarely triggers, or rules too lax | Check the rule actually covers real risk |
| Very low, many failures | Teams fix issues, or the process blocks overrides entirely | Check for side channels such as direct pushes |
| High, concentrated in one rule | That rule is noisy or wrong | Tune or retire the rule |
| High, concentrated in one team | Training or ownership gap | Talk to the team |
| Rising over weeks | Gate losing trust | Review thresholds with developers |
Capture the reason
Require a reason code on every override: false positive, accepted risk with a record, urgent production fix, rule needs tuning. Free text alone cannot be counted. Then report the split. A gate where most overrides are "false positive" is telling you to improve detection, not to scold developers.
Give overrides an owner and an expiry
An override for an urgent production fix is legitimate, but it should create a follow-up item with a due date. Treat an override like a small risk acceptance: who approved it, why, until when.
Steps
- Log every gate decision, pass, fail and override, with timestamps.
- Add reason codes and an approver field.
- Review the top overridden rules monthly.
- Convert recurring overrides into rule changes.
- Report override rate by rule and by team, alongside the number of gate runs.
Avoid
Do not set a target override rate of zero. A gate with no escape valve gets bypassed through the build system itself, which is worse because you cannot see it. Aim instead for overrides that are rare, explained and followed up.
Try it yourself
Open the demo and see how a pull request gate blocks a change. Think about which reason code you would want if you chose to release it anyway.
Click through it at your own pace, or open it full screen.
Safeguard supports this with policies, gates and guardrails, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Is a zero override rate good?
Not necessarily. It may mean teams route around the gate. Look for side channels.
What should an override record contain?
Who, when, which rule, a reason code, and a follow-up due date.
Last reviewed: 19 October 2026.
