How to Identify High Risk Pull Requests
Learn how to identify high risk pull requests using change scope, dependencies, production context, testing, history, and potential blast radius.

A high risk pull request is not simply a large pull request. Risk depends on the change and the system around it.
Useful signals
Look for shared components, critical services, broad dependency reach, customer facing behavior, database or infrastructure changes, authentication, limited testing, high churn, relevant incidents, unusual runtime behavior, and difficult rollback.
Large PR does not automatically mean high risk
A large change in an isolated component may have limited exposure. A small change in authentication, payments, routing, or a shared library can have much wider consequences.
Production context
Ask whether the component is business critical, how widely it is used, what traffic reaches it, which dependencies matter, and whether the area has been unstable recently.
Verification and history
Limited test coverage increases uncertainty. Previous incidents and recent change activity can reveal patterns that are not obvious in the current diff.
Use risk as a prioritization signal
The goal is not to label a PR as bad. The goal is to identify changes that deserve additional review, testing, staged deployment, or investigation.
Tomosu's Production Reliability Index (PRI) provides a change level reliability signal using multiple sources of evidence.
Explore PRI: https://tomosu.ai/start
About the author
- Tomosu continuously scores every application and closes its reliability gaps across development, pre-merge and runtime, using the Production Reliability Index (PRI) and a multi-tier agentic system.
Comments
Join the discussionNo comments yet. Be the first to comment.
The Production Reliability Series
A practical series on production reliability, covering how to evaluate software changes, dependencies, blast radius, testing, observability, pull request risk, and reliability before deployment.




