Skip to main content

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.

Updated 1 min readMarkdown
Part of seriesThe Production Reliability Series
How to Identify High Risk Pull Requests

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.

No comments yet. Be the first to comment.

The Production Reliability Series

Part 9 of 10

A practical series on production reliability, covering how to evaluate software changes, dependencies, blast radius, testing, observability, pull request risk, and reliability before deployment.

Up nextHow to Prioritize Risky Pull RequestsLearn how to prioritize risky pull requests using production impact, dependencies, testing, change scope, incident history, blast radius, and deployment conditions.