Deployment risk

At a glance

Input	What it indicates	Where it comes from
Size and shape of the diff	Broad or cross-cutting changes fail more often	Version control
Schema or config changes	Harder to roll back than application code	The change itself
Dependents of the target	How far a failure would spread	Observed dependency graph
Recent instability of the target	A service that failed last week is likelier to fail again	Incident history
Deploy recency and frequency	Long gaps mean larger, less understood changes	Deployment system
Rollback path	Whether a mistake is cheap or expensive to undo	Deployment tooling and schema strategy
Timing	Fewer people available to respond raises effective risk	The rota

How it works

Deployment risk has two components that are usually collapsed into one and should not be. The first is likelihood: how probable is it that this change misbehaves. The second is spread: if it does, how much breaks. A small, likely-buggy change to a leaf service is a different situation from a careful change to something forty services depend on, and treating both as a single number obscures the decision.

The likelihood side is mostly readable from the change and its history. Large diffs fail more often than small ones. Changes touching database schema or configuration are historically riskier than application code, and they are usually harder to reverse. A service that has been unstable recently is likelier to be unstable again. Long gaps between deployments raise risk because the change is larger and nobody has recent context on it.

The spread side is a dependency question. How many services call the target, how many of those calls are synchronous and unprotected, and how central is the target to paths users actually depend on. This is the same computation as blast radius, applied before the change rather than during the incident. Visualizing deployment blast radius covers drawing that spread for a specific change.

What makes this worth doing before rather than after is asymmetry. Assessing risk beforehand costs a query. Discovering it afterwards costs an incident, and the recovery path is usually a rollback, which is fast for application code and slow or impossible for a schema migration that has already run.

Most teams manage this entirely reactively, through rollback speed and canary deployments. Those are good and they are exposure controls rather than risk assessment: they reduce how many users meet the problem without telling you which changes deserve more care.

How it is measured

Score the two components separately and keep them separate in whatever you present. A combined number hides which lever to pull, since high likelihood is addressed by testing and review, while high spread is addressed by staging, feature flags and timing.

Derive the dependency side from observed traffic rather than declarations. A declared dependency list reflects what someone wrote down, and the dependency that causes the outage is usually the one nobody recorded. This is the same limitation that affects incident-time blast radius calculations, so check which kind your tooling uses. Scoring a proposed change before it runs is the same computation pointed forwards rather than backwards, which is why the two either share a dependency model or disagree with each other.

Calibrate against your own history. Take the last quarter's incidents, compute what the risk assessment would have said for each triggering deploy, and check whether the ones that caused problems scored higher than the ones that did not. An assessment that does not separate them is not measuring anything, and this check is skipped far more often than it is run.

Use the score to change behaviour, not to produce a report. The useful outputs are specific: this one goes out on Tuesday morning rather than Friday afternoon, this one gets a canary, this one needs the owning team available. How error budgets work and how they are spent covers the related mechanism for deciding when to slow down generally rather than per change.

Common misconceptions

That risk is proportional to lines changed. A one-line change to a shared configuration value can affect everything, while a thousand-line change confined to one endpoint may be trivially safe. What is touched matters more than how much.

That a canary makes assessment unnecessary. A canary only helps if the failure shows up in the signal being watched and within the observation window. Slow degradations and failures that only appear under production-scale load routinely pass canaries.

That frequent deployment is riskier. The consistent finding is the opposite. Small, frequent changes are individually safer and easier to attribute when something breaks, which is why deployment frequency and change failure rate tend to improve together. What change failure rate measures covers that pairing.

That rollback is always available. Application code usually rolls back cleanly. Schema migrations, data backfills and anything that has already been consumed by a downstream system often do not, and treating rollback as a universal safety net is how those become long incidents.

That risk assessment is a gate. Used as an approval checkpoint it becomes a form somebody fills in. Used as information attached to the deploy, it changes when a change ships, whether it gets a canary, and who is available when it does.