Merge Checks
Everything else in Firetrail is advice — the GitHub check always reports neutral, and nothing ever stops a merge. Merge Checks are for teams who decide they want some rules to have teeth.
We built them around an observation: most merge-blocking tools fail not because blocking is wrong, but because wrongly blocking is fatal. One false block on a Friday deploy and the team turns the tool off forever. So Merge Checks are designed to make a wrong block nearly impossible — every check has to prove itself before it's allowed to stop anyone, and even then there's always a way through.
Checks bind to facts, not the score
A check is never "block PRs that feel risky." Each one binds to a specific, objective thing Firetrail measured on the PR — so when a block happens, the reason is concrete and nobody has to argue with a number:
| Check | Fires when… |
|---|---|
| Coverage below floor | the estimated patch coverage is under the threshold you set — only when patch coverage is switched on for your organization; with it off, this check never fires |
| Pinned dependency bump | the PR truly changes a dependency — a version bump or a lockfile update |
| Global config change | the PR touches configuration with production blast radius |
| PR Quiz not taken | nobody has taken the PR Quiz on this PR |
Notably absent: the overall risk band. The Future Debug Cost is a judgment call, and judgment calls make bad gatekeepers. Facts make good ones.
Simulation first — enforcement is earned
Every check runs in one of two modes, and every check starts in the first:
- Simulation. The check watches every PR and records what it would have blocked — but blocks nothing, and the GitHub check stays neutral. The PR comment notes "Merge Checks — simulation (would block)", so the team sees what enforcement would feel like without living it.
- Enforce. A fired check reports the GitHub check as a real failure. Combined with GitHub branch protection, that blocks the merge.
The simulation report (Project settings → View simulation report) is each check's track record: PRs evaluated, would-have-blocked count, actual blocks, and measured precision — of everything it wanted to block, how much was genuinely block-worthy. A check auto-promotes from Simulation to Enforce only after its precision clears the bar across a real observation window. An owner or manager can promote one manually before that — but then they're accepting the risk explicitly, with the track record in front of them.
The break-glass override
A blocked PR is never a dead end — that's the design promise that makes enforcement tolerable. Two ways through, for real emergencies:
- add the
firetrail:overridelabel to the PR on GitHub, or - press Break-glass override on the simulation report.
Either flips the check back to neutral so the merge can proceed. Every override is recorded — who, when, which PR — so instead of a wall you get an audit trail, and instead of resentment you get data about which checks actually get overridden (a precision signal in itself).
Who can change what
Only organization owners and managers can create or edit checks, switch
modes, or use the in-app override. Members see the configuration read-only.
The firetrail:override label is the deliberate exception — it follows your
GitHub repository permissions, so in a genuine emergency, anyone who can
label a PR can get through.
Availability
Merge Checks are included on the Business plan. See Plans & billing.