How to Identify High Risk Pull Requests

Not every pull request deserves the same amount of scrutiny.

A documentation change and a modification to a shared authentication service can both be valid pull requests, but their potential production impact can be very different. The difficult part is identifying that difference before the change reaches production.

A useful approach is to look beyond the size of the diff and consider the context around the change. That includes:

• What changed
• What depends on it
• How widely it is used
• What production behavior looks like
• What testing was performed
• What has happened historically
• How large the potential blast radius is
• How the change will be deployed

The goal is not to label every pull request as safe or unsafe. It is to identify changes that deserve additional attention.

What is a high risk pull request?

Those characteristics can include:

• Changes to shared components
• Changes to critical services
• Large dependency reach
• Customer facing behavior
• Database or infrastructure changes
• Authentication or authorization changes
• Limited testing
• Significant recent code churn
• Previous incidents in the affected area
• Unusual runtime behavior
• Difficult rollback conditions

There is no universal threshold that makes a pull request high risk. The same change can have different implications depending on the architecture, production usage, and deployment process.

Start with the change itself

The first step is understanding what the pull request actually modifies. Look at files changed, components changed, lines added and removed, APIs modified, database changes, configuration changes, infrastructure changes, and shared libraries.

Diff size can be a useful context, but it should not be treated as a complete risk signal. A five line change to a shared authentication library may deserve more attention than a 500 line change to an isolated internal tool.

1. Check whether shared components are involved

Shared components can create a large potential blast radius.

For a deeper process, see How to Assess the Blast Radius of a Code Change.

2. Look at what the changed code does

Some parts of a system have more production significance than others. Pay attention to changes involving:

• Authentication and authorization
• Payments and billing
• Databases
• Core APIs
• Data processing
• Infrastructure and deployment systems
• Shared libraries
• Customer facing workflows

This does not mean these changes are automatically high risk. It means their production context can make the consequences of failure broader.

3. Check the dependency graph

Next, look beyond the files in the pull request. Ask:

• What services depend on this component?
• Which APIs consume the changed behavior?
• Are shared libraries involved?
• Are external systems involved?
• Does the change affect a database used by multiple services?

For example, a pull request that changes a shared API client used by six services reaches multiple production workflows. A change with this kind of dependency reaches more context than an isolated change.

4. Look at production usage

Dependency relationships tell you what could be affected. Production usage helps determine what that impact could mean. Consider:

• Number of production consumers
• Request volume
• Customer facing paths
• Business critical workflows
• Internal versus external users
• Geographic scope

A dependency used by one internal service is different from one used across the main customer API. This is one reason static code analysis alone cannot provide the entire picture.

5. Check testing and verification

Next, look at the evidence supporting the change: unit tests, integration tests, end to end tests, regression tests, load tests, staging verification, and manual testing.

The important question is not simply:

Did CI pass?

Ask:

What behavior did the tests actually verify?

A pull request can have a green CI pipeline while important production paths remain untested. For the broader measurement framework, see How to Measure Software Change Reliability.

6. Check recent change activity

Recent activity can provide useful context. Look at the number of recent changes, deployment frequency, recent refactoring, related pull requests, multiple concurrent changes, and recent ownership changes.

A component that has changed repeatedly over a short period may deserve additional investigation, especially if the current change also has broad dependency reach. This is a signal, not a universal rule.

7. Look at production behavior

Current production behavior can change how you evaluate a pull request. Check relevant error rates, latency, resource usage, dependency failures, alerts, and runtime anomalies.

For example, a change touching a service that is already experiencing elevated errors may warrant more investigation than the same change touching a stable service.

This is where observability becomes useful. For more on the relationship, see Production Reliability vs Observability.

8. Check incident history

Previous incidents can provide additional evidence. Ask:

• Has this component caused incidents before?
• Have similar changes caused problems?
• Has this dependency required rollback?
• Are there recurring failure patterns?
• Has this part of the system recently recovered from an incident?

Past incidents do not prove that a new change will fail. They provide historical context that can help determine how much additional verification is appropriate.

9. Assess the blast radius

Once you understand the change and its dependencies, map the potential impact: changed component → direct dependencies → downstream services → production workflows → potential user impact. Ask:

• How many components could be affected?
• Are customer facing systems involved?
• Are critical workflows involved?
• Can the affected area be isolated?
• What happens if the change behaves unexpectedly?

For a detailed walkthrough, see How to Assess the Blast Radius of a Code Change.

10. Consider rollback and deployment controls

A pull request's potential impact also depends on how it will reach production. Consider feature flags, canary releases, gradual rollout, regional rollout, automated rollback, manual rollback, and monitoring during deployment.

A change with broad reach and no practical rollback path may deserve more scrutiny before merge. A broad change with strong isolation and gradual rollout may have more operational controls around it.

A practical high risk pull request checklist

Before merging, ask:

These questions create a much better picture than simply sorting pull requests by lines changed.

How to prioritize risky pull requests

Once potentially high risk pull requests have been identified, teams can prioritize engineering attention based on the evidence. For example, consider two changes.

A useful prioritization process considers multiple signals together. Possible actions include additional review, more testing, dependency investigation, smaller change scope, a feature flag, gradual rollout, and additional monitoring.

The appropriate action depends on the team's architecture and reliability requirements.

Should high risk pull requests always be blocked?

No single rule applies to every engineering organization. A high potential impact change does not automatically mean it should not merge. Instead, the assessment can trigger additional controls.

High risk does not mean large diff

This distinction is worth emphasizing. A pull request with many changed lines is not automatically more likely to cause a production problem. Likewise, a tiny pull request is not automatically safe.

The first change may have a much broader potential production impact.

This is why change context matters more than diff size alone.

Production Reliability Index

Tomosu uses the Production Reliability Index (PRI) to bring multiple reliability signals into a broader view of changes and production systems. The platform describes PRI as a master score built from seven sub indices:

• Fragility Index
• Drift Index
• Governance Compliance
• Runtime Signals
• Code Volatility
• Deployment Velocity
• Escalation Index

These signals are calibrated to the organization and used across development, pre merge, and production.

The idea is to bring multiple pieces of reliability evidence together rather than treating one signal, such as diff size or test status, as the complete picture. See also Production Reliability vs Code Review for why the diff alone rarely tells the whole story.

Try the Production Reliability Index →

The main idea

A pull request is more than a diff. Its potential production impact depends on what changed, what depends on it, where it runs, what has happened before, and how the change will be deployed.

That context can help engineers identify which pull requests deserve more attention before they reach production. It sits naturally inside pre merge reliability analysis and the broader question of what production reliability means.

For the next step, see How to Prioritize Risky Pull Requests. You can also check How to Assess Production Reliability Before Deployment.

Frequently asked questions

A pull request is more than a diff. Tomosu's Production Reliability Index brings dependencies, runtime signals, history, and deployment context together so the changes that deserve attention stand out before they merge. Try the Production Reliability Index →