Change risk and release radar

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 history.
Production errors	Open production errors and incidents linked to the changed code: 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).
• 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.