A pull request can pass tests, static analysis, and code review and still introduce a production reliability problem.
That does not mean those checks are ineffective. It means they answer different questions. Before merging a change, engineers can also ask:
What does this change mean for the reliability of the production system?
That is the purpose of pre merge reliability analysis. Instead of looking only at whether the code is correct, it considers the change alongside its dependencies, affected components, production behavior, historical incidents, testing, and potential blast radius.
What is pre merge reliability analysis?
Pre merge reliability analysis is the process of evaluating a software change before it is merged into the main codebase, using evidence about both the change and the production system it will affect.
The analysis can consider:
- What changed
- Which components are affected
- Which dependencies are involved
- How widely those components are used
- What testing was performed
- Current production behavior
- Previous incidents
- Recent change activity
- Deployment conditions
- Potential blast radius
The goal is not to predict the future with certainty. It is to identify reliability concerns while there is still an opportunity to investigate, test, modify, or delay the change.
For the broader concept, see What Is Production Reliability in Software Engineering?.
Why analyze reliability before merge?
The earlier a reliability concern is found, the more options engineers have. After a change is merged, it can move through CI, deployment, staging, production, and eventually reach users.
Before merge, the engineer can still change the implementation, add tests, investigate a dependency, reduce the scope, add a feature flag, request another review, split the change into smaller pieces, or delay the merge.
This makes pre merge analysis useful as an additional decision point. It does not need to replace existing checks.
What should you evaluate before merge?
A practical pre merge analysis can be broken into several areas.
1. Change scope
Start with the change itself. Ask:
- How many files changed?
- Which components changed?
- Is the change isolated or cross cutting?
- Does it modify shared code?
- Does it alter an interface or contract?
- Does it change behavior or only implementation details?
A small diff does not automatically mean a small production impact. A two line change in a shared library can affect more systems than a large change isolated to an internal tool.
2. Affected components
Identify what the change can reach. For example:
The important question is not only how much code changed. It is how much of the system depends on that code. This is where dependency and blast radius analysis become important. For more on this, see How to Assess the Blast Radius of a Code Change.
3. Dependencies
Look beyond the files directly modified by the pull request. Consider:
- Internal libraries
- APIs
- Databases
- External services
- Shared infrastructure
- Authentication systems
- Queues
- Storage systems
A change can be locally correct while interacting badly with a dependency under production conditions. Dependency analysis therefore provides useful context for pre merge reliability analysis.
4. Testing and verification
Next, look at what evidence exists that the change behaves as expected. This can include unit tests, integration tests, end to end tests, regression tests, load tests, manual verification, staging results, and existing production behavior.
The important question is not simply:
Did the tests pass?
It is:
What parts of the changed behavior did the tests actually verify?
A change with extensive coverage of the affected behavior provides different evidence from one with only a small set of unit tests. For the measurement side of this process, see How to Measure Software Change Reliability.
5. Production behavior
Production can provide useful evidence even before a new change is deployed. Look at the current behavior of the components affected by the pull request. Relevant signals might include error rates, latency, resource usage, recent anomalies, dependency failures, incident history, and service health.
For example, a change touching a service that has experienced repeated latency problems deserves a different investigation from the same change affecting a stable service.
Observability provides much of this runtime evidence. See Production Reliability vs Observability for the distinction between observability and change reliability analysis.
6. Historical incidents
Past production behavior can provide another useful signal. Ask:
- Has this component caused incidents before?
- Have similar changes caused problems?
- Was there a previous rollback?
- Has this dependency experienced reliability issues?
- Are there recurring failure patterns?
The purpose is not to assume that a previous incident means the new change will fail. It is to avoid evaluating the change without information the team already has.
7. Recent change activity
Code that changes frequently can require additional attention. Consider recent commits, recent deployments, the number of changes to the component, whether several changes are being made simultaneously, and whether the component is already undergoing significant modification.
This can provide useful context when combined with the actual change being reviewed.
8. Deployment conditions
The same change can have different operational conditions depending on how it will be deployed. Consider feature flags, gradual rollout, canary deployment, rollback capability, deployment size, and monitoring during rollout.
A change with a large potential blast radius and no easy rollback path may deserve more investigation before merge.
Pre merge reliability analysis vs code review
These processes overlap, but they are not identical.
| Code review | Pre merge reliability analysis | |
|---|---|---|
| Generally asks | Does this implementation make sense? | What could this change mean for the reliability of the production system? |
| On a new database query | Is the query correctly implemented? | How frequently will it execute? Which services call it? What database does it affect? What has that database been doing recently? How large could the impact be? What happens if performance degrades? |
Both perspectives are useful.
For a deeper comparison, see Production Reliability vs Code Review.
What is production aware code review?
Production aware code review extends the review context beyond the diff itself. Depending on the implementation, it can incorporate information such as dependency relationships, runtime behavior, production telemetry, incident history, ownership, historical changes, and deployment information.
The distinction is mostly about the question being asked. Traditional review focuses heavily on the implementation. Production aware review brings more production context into that evaluation. Pre merge reliability analysis takes that idea further by explicitly evaluating the reliability implications of the proposed change.
Where static analysis fits
Static analysis remains another important pre merge signal. It can identify known coding patterns, security issues, type problems, dependency issues, architecture violations, and other detectable conditions.
But static analysis does not necessarily know how important a component is to the production system. That is why it can be combined with broader reliability analysis. See Production Reliability vs Static Analysis.
A simple pre merge reliability workflow
A practical workflow could look like this:
The important part is that the output should lead to an action. A reliability signal is useful when it helps the team decide what to investigate or change.
What should block a merge?
There is no universal threshold that should block every change. The appropriate action depends on the organization's architecture, reliability requirements, and deployment process. A reliability assessment might lead to:
- Merge normally
- Request additional testing
- Investigate a dependency
- Reduce the scope of the change
- Add a feature flag
- Use a gradual rollout
- Require additional review
- Delay the merge
The goal is not to stop every change that looks uncertain. It is to make important uncertainty visible before the change becomes harder to control.
Production Reliability Index
Tomosu uses the Production Reliability Index (PRI) to bring multiple reliability signals into a broader view of the change and production environment. 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. That makes PRI relevant to the pre merge stage because the goal is to surface reliability context while a change can still be investigated or modified.
Explore the Production Reliability Index →
A practical pre merge checklist
Before merging a change, ask:
- What exactly changed?
- Which components were modified?
- Is shared or critical code involved?
- What depends on the changed code?
- Are external services or shared libraries involved?
- What has been tested?
- What has not been tested?
- Does the testing cover the important changed behavior?
- What does current production behavior look like?
- Are there recent anomalies or incidents?
- Has this component caused problems before?
- Have similar changes caused incidents?
- How many components or users could be affected?
- What happens if the change behaves unexpectedly?
- Can the change be rolled back?
- Can it be deployed gradually?
- What signals will be monitored after deployment?
The point is not to turn every pull request into a manual investigation. The point is to have enough context to distinguish a routine change from one that deserves more attention.
The main idea
Pre merge reliability analysis is not another replacement for code review, testing, or static analysis. It adds another question to the process:
What does this change mean for the production system?
The useful evidence can come from many places:
The earlier that context is available, the more options engineers have to act on it.
For the next step, see How to Assess Production Reliability Before Deployment or How to Measure Software Change Reliability.
Frequently asked questions
What is pre merge risk analysis?
Pre merge risk analysis evaluates the potential production consequences of a software change before it is merged. The analysis can consider change scope, dependencies, testing, production behavior, incident history, and blast radius.
Is pre merge risk analysis the same as code review?
No. Code review focuses primarily on the implementation. Pre merge reliability analysis considers the implementation together with production context.
What is production aware code review?
Production aware code review incorporates production information such as runtime behavior, dependencies, incidents, ownership, and historical changes into the review process.
Can tests determine whether a change is reliable?
Tests provide important evidence, but they cannot necessarily reproduce every production condition or dependency interaction.
Does every high uncertainty change need to be blocked?
Not necessarily. The appropriate response can range from additional testing to a gradual deployment, investigation, or merge depending on the change and the organization's controls.
When should reliability analysis happen?
It can happen during the pull request lifecycle, before merge, when the team still has an opportunity to investigate or modify the change.
The earlier reliability context is available, the more options engineers have to act on it. The Production Reliability Index brings that context to the pull request, while the change can still be investigated or modified. Try the Production Reliability Index →
