# Merge gate > One safe-to-merge verdict per pull request, with a merge readiness score and a checklist of exactly what to do to pass, reported as a status check. A review tells you what is wrong. The merge gate tells you whether the pull request is safe to merge, and if not, what to do about it. For every commit of every pull request, MergeHarbor combines everything it knows into one verdict: - **Ready to merge**: every check in your policy passed. - **Ready with warnings**: nothing blocks the merge, but some checks need a look. - **Blocked**: something in your policy must be fixed first. - **Waiting for review**: the latest commit is still being reviewed. Alongside the verdict you get a **merge readiness** score from 0 to 100 and a checklist, most important first, where every item says what to do: "Fix: refund amount is not validated", "Meet criterion 2 of PAY-12", "Add tests for `Partial()` in pay/refund.go", "Get 1 more approval". ## What the gate looks at | Signal | What counts | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Review | The review's confidence score for the latest commit. | | Open findings | Unresolved findings by severity. Resolved and dismissed findings no longer count. | | Proof runs | A finding that a generated test reproduced in the sandbox counts as proven. Generated tests that passed raise readiness. | | Requirements | Acceptance criteria of linked Jira or Linear issues that the review found unmet. | | Tests | Changed-line coverage and changed functions without tests, where they are measured. | | Change risk | How risky the change is: what it touches and how widely. | | Approvals | People (not bots) whose latest review on the code host approves the pull request. | | Rules and configuration | Findings from your team's rules, and errors in `.mergeharbor` files. | | Dependencies | Vulnerable or denied-license packages the pull request adds or upgrades (with the Security add-on). If the check can't run, the gate warns by default; you can let it pass or block until it runs. | A signal that is not measured for a repository never blocks; the checklist says it was not checked. Merge readiness is the weighted average of the measured signals, kept within the verdict's range (blocked 0-49, warnings 50-79, ready 80-100), so the number and the verdict always agree. ## Where you see it - **On the code host** as its own check, **MergeHarbor / merge gate**, next to the review check (which it never changes). GitHub shows it as a check run with the checklist; GitLab, Bitbucket, Gitea and Azure DevOps show a commit or pull request status. - **In the console**: at the top of every pull request, as a column and filter in the pull request list, and under **Insights → Risk → Merge gate**. The gate is checked again whenever something changes: a new push, a finding resolved or dismissed, a review or proof run finishing, requirements or approvals changing, or your policy changing. **Check again** on the pull request reads everything immediately. ## Stop merges that are not ready To stop merges on the code host, make the check required: - **GitHub**: add **MergeHarbor / merge gate** as a required status check in branch protection or a ruleset. A warning shows as neutral and still lets the pull request merge. - **GitLab**: the gate posts a commit status named **MergeHarbor / merge gate**. On GitLab Ultimate, add an external status check whose name contains "MergeHarbor" (Settings → Merge requests → Status checks); MergeHarbor answers it as passed or failed for each commit. - **Azure DevOps**: add a branch policy requiring the status `mergeharbor/merge-gate`. - **Bitbucket and Gitea**: require the **MergeHarbor / merge gate** build status or commit status. Merges started from MergeHarbor (single or bulk) always respect the gate. ## Policies Configure the gate under **Settings → Checks & gates → Merge gate**. Start from a preset and change any check: | Preset | In short | | ------------------ | ----------------------------------------------------------------------------------- | | Relaxed | Only critical findings and findings a test proved block. | | Standard (default) | Also blocks a review confidence below 3/5; warns on tests, risk and unmet criteria. | | Strict | Blocks major findings, unmet criteria and team-rule violations; needs 1 approval. | | Regulated | Coverage, test gaps and high risk block; needs 2 approvals and expects a proof run. | **Branch policies** make the gate stricter (or looser) for some target branches, for example Strict for `main` and Regulated for `release/*`. The first matching pattern wins. **Advisory mode** (the default) reports the verdict without ever failing the check. Switch to **Enforce** in Settings → Checks & gates → Merge gate when you want a failing verdict to fail the check, so a required check stops the merge. Advisory is also a good way to try a stricter policy first. Policies cascade like every other setting: the organization's policy, a repository's own policy, then `.mergeharbor.yml` in the repository. The organization can lock the policy so repositories cannot weaken it. ```yaml # .mergeharbor.yml merge_gate: enabled: true mode: enforce # or advisory preset: standard # relaxed | standard | strict | regulated rules: required_approvals: 1 min_coverage: 70 branches: - pattern: "release/*" preset: regulated ``` Every check you can change is in the [configuration reference](https://mergeharbor.com/docs/configuration). ## Overrides Sometimes a blocked change must ship. People with the **Override a blocked merge gate** permission (owners and admins by default) can override the gate for one commit with a reason, from the pull request or the merge dialog. The check then passes and says who overrode it and why, MergeHarbor comments on the pull request, and the override is in the audit log. A new push is checked again. Turn overrides off in the policy to forbid them. ## Analytics **Insights → Risk → Merge gate** shows, for merged pull requests: how many were ready, how many were blocked and then fixed before merging, how many were overridden, how many merged on the code host while blocked, and how many passed but were reverted later. It also shows what blocks merges most and the recent overrides with their reasons.