Time to unblock is the span from a gate failing to the same change passing the gate, by fix, exception or override. It is often the biggest hidden part of gate friction. Measure it in stages, find where changes wait and attack the longest stage.
Why this beats a failure count
A gate that fails often but gets resolved in minutes is a minor cost. A gate that fails rarely but leaves changes stuck for days is a big one. Counts of failures cannot tell the two apart. Time to unblock can.
Define the span
- Start: the first failed gate result on a change.
- End: the first later passing result on that same change, whatever the route.
- Record the route: fix, exception, override or the gate being reconfigured.
Use medians and a high percentile. A few stuck changes will dominate any average.
Split it into stages
| Stage | Question it answers |
|---|---|
| Noticed | How long until someone opened the failure? |
| Understood | How long until they knew what it meant? |
| Fixed or decided | How long to patch, or to get an exception or override? |
| Re-run and pass | How long for the pipeline to confirm? |
You will need timestamps beyond CI, such as the first view of the check, a linked ticket or the exception request. Where you lack them, start with total span and add stages as you instrument.
Typical causes of waiting
- Unclear failure messages, so developers must hunt for the cause.
- No named owner for exception decisions, or an approver who is away.
- A fix that exists but needs a major version upgrade the team has not scheduled.
- No fix available, so the choice is exception or wait.
- A slow pipeline that makes each re-run expensive.
What to do
- Rewrite failure messages to say what failed, why it matters and the first thing to try.
- Name exception approvers with deputies, so one absence does not stall a release.
- Give approvers a service expectation for response time, and track it.
- Publish a short guide for common failure causes with exact steps.
- For findings with no available fix, offer a pre-agreed path with an expiry date.
Reading the result
If noticed is long, improve notification. If understood is long, improve messages. If fixed or decided is long, look at ownership and approval paths. If re-run is long, look at pipeline speed. Each stage has a different owner, so the split directs the work.
Keep the metric about the process and not about individual developers. Publishing names turns a diagnostic into a scoreboard and invites hiding failures.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a developer sees when the gate blocks, and whether the next step is obvious.
Quick check
Does an override count as unblocked?
Yes, but record the route. A pile of overrides with short unblock times can mean the gate is being bypassed.
What if the change was abandoned?
Record it as closed without pass, and report it separately. Abandoned changes after a block may signal friction.
How Safeguard fits
Safeguard offers policies, gates and guardrails with dependency scanning, and an autonomous remediation capability that can open fix pull requests, off by default with every category on Manual. Try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
