Code review asks whether a change looks correct. Production reliability asks what that change could mean once it reaches a running production system.
They overlap, but they are not the same thing.
A reviewer can examine a pull request and catch incorrect logic, bad patterns, missing tests, or a bug in the implementation. But the code can still look correct while introducing problems through a dependency, shared component, production condition, or unexpected blast radius.
That is the gap production reliability analysis is trying to address. If you're new to the concept, start with What Is Production Reliability in Software Engineering?.
What does code review actually measure?
Code review is primarily concerned with the change itself. Depending on the team and review process, a reviewer might look at:
- Whether the implementation matches the requirements
- Logic errors
- Code quality
- Security issues
- Maintainability
- Test coverage
- API changes
- Architectural concerns
- Potential bugs
The reviewer is looking at the proposed change and the context available to them. That makes code review an important control before a change is merged.
But there is a practical limitation:
The diff does not contain the entire production system.
A reviewer might understand the affected code extremely well and still not have complete information about everything that could happen when the change interacts with production.
What does production reliability measure?
Production reliability looks at the change in relation to the system around it. That can include:
- Affected components
- Dependencies
- Production behavior
- Incident history
- Code volatility
- Testing and verification
- Deployment conditions
- Rollback options
- Potential blast radius
The question changes from:
Does this code look correct?
to:
What evidence do we have about how this change will behave in production?
That doesn't make the second question a replacement for the first. They are looking at different parts of the same change.
Code review vs production reliability
| Code review | Production reliability | |
|---|---|---|
| Primary question | Does the change look correct? | What could this change mean for production? |
| Main input | Code and review context | Code plus system and production context |
| Dependencies | May be considered | Explicit part of the assessment |
| Tests | Reviewed as evidence | Considered alongside other evidence |
| Production behavior | Usually indirect | Directly relevant |
| Incident history | May be considered | Relevant context |
| Blast radius | May be considered | Central consideration |
| Rollback | Often outside the review itself | Part of deployment context |
| Main output | Review comments / approval | Reliability signal and supporting evidence |
The two processes can use some of the same information. The difference is how that information is used.
A simple example
Imagine a pull request changes a shared database library. The diff is small. The implementation is correct. Unit tests pass. The reviewer approves the change.
But the library is used by six production services. One of those services has recently experienced database connection problems. The new implementation also changes how connections are reused.
Nothing in the code necessarily looks obviously wrong. The production context changes the question. The useful question is no longer just:
Does this implementation work?
It is also:
What could change because this shared component is behaving differently?
That is where production reliability analysis adds another layer of context.
Why code review can miss production impact
A code review is necessarily constrained by what the reviewer can see and understand during the review. Production systems introduce additional variables. For example:
Dependencies
A change may affect another service indirectly.
Runtime behavior
A change may behave differently under real traffic than it does in tests.
Historical behavior
The affected component may have previously caused incidents.
System relationships
A shared component can have a much larger blast radius than its diff suggests.
Deployment conditions
A change may be difficult to roll back or may require a particular rollout strategy.
None of these necessarily means the code is wrong. They change the context in which the code will run.
Does production reliability replace code review?
No. Code review and production reliability analysis serve different purposes.
Code review remains useful for examining implementation details and catching problems visible in the change itself. Production reliability analysis adds system level and production context around the change. A useful workflow can therefore look like:
The point isn't to add another approval layer for the sake of having one. The point is to surface information that isn't obvious from the diff itself.
What is production aware code review?
The term production aware code review can describe a review process that incorporates more information about the environment where the code will run. That can include:
- Dependency relationships
- Production telemetry
- Previous incidents
- Service ownership
- Runtime behavior
- Historical changes
- Deployment information
This starts to overlap with production reliability analysis. The distinction is mainly about the question being answered. A production aware review still centers the review around the code change. Production reliability analysis can go one step further by explicitly assessing the reliability implications of the change across the production system.
Production risk vs code review
You may also see this topic described as production risk vs code review. Production risk focuses on the potential downside of a change reaching production. Code review focuses primarily on evaluating the proposed implementation.
The underlying evidence can overlap. Dependencies, blast radius, testing, incident history, production behavior, and deployment conditions can all contribute to understanding a change. The terminology differs, but the practical question is similar:
What do we know about this change before it reaches users?
Tomosu uses the term production reliability because the goal is not only to identify potential failure. It is to build a broader picture of how a change relates to the reliability of the production system.
Code review and AI generated code
The distinction becomes more relevant as AI coding tools increase the volume of generated changes.
An AI code review tool can examine a large number of pull requests and identify potential problems in the code. That can be useful. But increasing the number of changes being reviewed also increases the amount of production context engineers may need to process.
A generated change can pass automated review while still:
- Touching a heavily shared component
- Increasing dependency exposure
- Interacting with an existing production issue
- Expanding the blast radius
- Changing behavior in an area with a history of incidents
The question isn't whether AI code review is useful. It is whether code level review is enough to understand the production implications of every change.
Where observability fits
Observability provides another piece of the picture. It can show errors, latency, resource usage, traces, dependency behavior, and runtime events. That tells engineers what is happening in production.
But observability is primarily about the running system. Code review is primarily about the proposed change. Production reliability sits between those two contexts by asking how a proposed change relates to the production system.
For more on this distinction, see What Is AI Observability?.
Where the Production Reliability Index fits
The Production Reliability Index (PRI) is Tomosu's approach to bringing multiple reliability signals into a single trendable score. Tomosu 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
The score is intended to summarize the broader reliability picture while keeping the underlying signals available for investigation. That gives engineers a different signal from a simple code review approval. A review can tell you that the change passed the review process. PRI is intended to provide a broader view of the reliability context around the system and its changes.
See the Production Reliability Index →
The two questions to keep separate
A useful way to think about the difference is:
| Code review | Production reliability |
|---|---|
| Does this change look correct? | What does this change mean for the reliability of the production system? |
You want answers to both. A change can be technically correct and still have a large production blast radius. A change can also have a small production footprint while containing an obvious implementation bug. Neither question makes the other unnecessary.
A practical workflow
For a significant change, a team could think about the process in four stages:
Review the change
Look at the implementation, logic, tests, architecture, and security implications.
Understand the production context
Look at dependencies, affected components, current production behavior, incident history, and code volatility.
Evaluate deployment conditions
Understand rollout strategy, monitoring, rollback options, and what signals would indicate a problem.
Decide what evidence is needed
More testing, another review, a smaller rollout, a feature flag, a rollback plan, or additional monitoring.
The goal isn't to make every pull request slower. It's to make the important production context visible before it matters. If you want the step by step version, see How to Assess Production Reliability Before Deployment, and for the measurement side, How to Measure Software Change Reliability.
A change can be technically correct and still have a large production blast radius.
Frequently asked questions
Is production reliability the same as code review?
No. Code review primarily evaluates whether a proposed implementation looks correct. Production reliability analysis considers the change in relation to dependencies, production behavior, incident history, deployment conditions, and potential blast radius.
Can code review identify production risk?
It can identify some signals that contribute to production risk, especially when reviewers understand the affected system well. But the code review process does not necessarily contain all of the production context needed to evaluate a change.
What is production aware code review?
Production aware code review is a review approach that incorporates information about the environment where the change will run, such as dependencies, runtime behavior, production telemetry, and incident history.
Does production reliability replace code review?
No. They answer different questions and can be used together.
How does AI code review fit into production reliability?
AI code review can automate parts of code level analysis and help reviewers identify potential issues in changes. Production reliability analysis adds context around how those changes could interact with the running system.
Is observability part of production reliability?
Observability can provide useful evidence for production reliability analysis. It tells you about the behavior of the running system, while reliability analysis connects that information to a particular change and its potential production impact.
A review tells you the change passed the review process. The Production Reliability Index is Tomosu's broader view of the reliability context around the system and its changes. See the Production Reliability Index →
