# Change risk and release radar

> Every review scores how risky a pull request is to merge, from 0 to 100, and says why. The release radar shows what is risky in your next release.

Every review gives the pull request a **change risk** score from 0 to 100 and a level, with the reasons behind it. The score answers a different question from the review's findings: not "what is wrong with this code" but "how careful should we be when this ships". A small, correct change to a payments migration that was reverted last month can still deserve a careful rollout.

Scoring uses data MergeHarbor already has. It makes no extra model calls and uses no credits.

| Level    | Score  | What it suggests                                  |
| -------- | ------ | ------------------------------------------------- |
| Low      | 0–24   | Few or no risk signals                            |
| Medium   | 25–49  | Some risk signals; a normal careful review        |
| High     | 50–74  | Review carefully before it ships                  |
| Critical | 75–100 | Merge with extra care; have a rollback plan ready |

## What goes into the score

Each signal adds up to its **weight** in points. The total is capped at 100.

| Signal                     | What MergeHarbor looks at                                                                                                                              |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Blast radius               | How much other code depends on what changed: callers, implementations and readers of changed configuration, from the code graph and impact analysis.   |
| Hot spots                  | Changed files that changed often in the last 90 days, or had serious findings in that time.                                                            |
| Past reverts and incidents | Reverts, rollbacks, hotfixes and incidents in the last year that touched the same files, from the [generated docs](https://mergeharbor.com/docs/knowledge-base) history.      |
| Production errors          | Open production errors and incidents linked to the changed code: [Sentry](https://mergeharbor.com/docs/sentry), Datadog, CloudWatch, Cloud Logging and PagerDuty.             |
| Sensitive areas            | Authentication, payments, secrets and cryptography, database migrations, infrastructure, and API contract files (Protocol Buffers, GraphQL, OpenAPI).  |
| Size and churn             | Lines and files changed (documentation, lockfiles and generated files do not count), and files removed.                                                |
| Missing tests              | Source code changed without any test change, especially when no existing test exercises it, or test gaps the review reported.                          |
| Open serious findings      | Critical and major findings on the pull request that are not resolved yet.                                                                             |
| Change signals             | A security or urgent label, a release or hotfix target branch, and the repository's criticality. A repository marked low criticality lowers the score. |

Callers are found through imports, receiver types and declared types in Go, TypeScript and JavaScript, Python and Java, so a method that shares its name with a method on another type does not inflate the blast radius. Calls the code graph cannot resolve still count, matched by name. Other languages are matched by name.

A change that only touches documentation or tests keeps a quarter of its points.

Open serious findings set a minimum level: with an open critical finding the change is at least **High**, with an open major finding at least **Medium**. When that raises the score, the explanation lists **Raised for open findings** and says why, for example _raised to Medium because 1 major finding is still open_. A weight of 0 for open serious findings turns this off too.

When the data behind a signal is not available (no error tracker is connected or mapped to the repository, or the repository's history has not been read yet), the signal adds nothing and the console says it was not checked. A low score therefore never hides a gap in what was looked at.

The score covers the whole pull request at its latest commit, and is updated with each review.

## Where you see it

- **On the code host**: one line in the review summary, for example _Change risk: High (62/100) · touches database migrations · 1 earlier revert touched these files in the last year · Why_. **Why** opens the explanation in the console. An administrator can turn the line off.
- **Pull requests**: a **Risk** column, and a **Change risk** filter.
- **A pull request's page**: the **Change risk** card lists each signal that added points, with its explanation and evidence: the files, commits, Sentry issues or findings it is based on.
- **Coding agents**: the MCP tool `get_change_risk` returns the score, level and reasons (see [IDE and agents](https://mergeharbor.com/docs/ide-and-agents)).
- **API**: `GET /api/v1/orgs/{org}/pulls/{pull_id}/risk`, and `risk_score` and `risk_level` on pull requests, with `?risk=high,critical` and `?min_risk=` filters.

## Release radar

**Insights → Release radar** answers "what is risky in our next release?". It shows, for every repository you can see:

- open pull requests (not drafts) into the default branch or a release branch, and
- pull requests merged into those branches since the last release.

Changes are grouped by repository and sorted by risk, each with its top three reasons. Filter by repository, level and state, and download the list as CSV.

**Since the last release** starts at the newest release tag on the repository's default branch. MergeHarbor looks for new tags after each push to the default branch. A repository without tags shows the last 7 days. You can also pick the last 7, 14 or 30 days, or a custom range.

### Weekly digest

Turn on **Weekly release risk digest** in **Settings → Checks & gates → Change risk**. On Monday mornings (UTC), people who can see analytics get a notification when high or critical changes are headed for the next release. It shows counts only; the release radar shows the details each person is allowed to see. Each person decides in **Settings → Alerts & webhooks** whether **Release risk** notifications also come by email.

## Settings

**Settings → Checks & gates → Change risk** (needs the settings permission to change):

- **Weights**: pick a preset or set your own.
  - **Balanced** (default): every signal counts.
  - **Stability first**: weighs past reverts, incidents, production errors and hot spots most.
  - **Security first**: weighs sensitive areas, open findings and security labels most.
  - **Custom**: 0 to 50 points per signal; 0 turns a signal off.
- **Show change risk in the review summary**: on by default.
- **Release branches**: which branches count as releases besides each repository's default branch. The change signals factor and the Auto review tier read the same list. `*` matches anything. The defaults are `release/*`, `release-*`, `releases/*`, `hotfix/*`, `production`, `prod` and `stable`.
- **Weekly release risk digest**: off by default.

New weights apply to reviews from then on; scores already shown keep the weights they were computed with. Changes are recorded in the audit log.