Skip to main content
Powered by Titan Foresight

You find out your blast radius in the post-mortem.

A PR ships. Something breaks. Three services you didn't know depended on this one start erroring. The post-mortem question, “did anyone check the dependency graph?”, has no good answer, because there was no tool that did it automatically before the deploy.

The situation

"The PR looked fine. Two approvals. Staging passed. It shipped Thursday at noon. By 12:40, three teams were paging."

The change was 200 lines. It touched a shared auth utility that eight services called. Nobody knew, not because they were careless, but because that dependency information lives in a graph that nobody maintains, nobody queries before merging, and nobody thinks about until it's the subject of a post-mortem action item that also doesn't get done.

The real problem

Deploy risk is a function of four things: what changed, what depends on it, how healthy your error budget is, and when you're shipping. Most teams have none of these systematically available at merge time. They rely on reviewer familiarity, which is tribal knowledge that doesn't scale. The senior engineer who knows every dependency is one vacation away from being the single point of failure in your release process.

And even when teams do check (manually pulling up Datadog before a deploy, eyeing the error budget, pinging the downstream service owners), none of that is connected to a deploy gate. A high-risk PR can still ship on a depleted error budget on a Friday afternoon, because nothing blocks it.

Cost of staying put

70%

of prod incidents

trace back to a deploy. Most were foreseeable: the blast radius was knowable before the change shipped.

5–15 min

per PR, per reviewer

spent mentally mapping dependencies that a system could compute in under 2 seconds. Every single PR.

1 engineer

who knows the graph

Most teams have a single person who intuitively knows which services depend on what. That's your single point of failure.

The fix

Risk intelligence needs to be automatic, pre-merge, and connected to a deploy gate. Not a dashboard someone checks. A system that reads every PR, walks your live dependency graph, checks your error budget balance, and surfaces a single risk score with a recommendation, as a PR comment, before anyone approves. High-risk changes get a soft block or a require-SRE-sign-off. The information that used to live in one senior engineer's head becomes systematic, enforced, and auditable.

Risk model

Six factors. One score.

Titan Foresight weighs six signals against your specific service's history and dependency graph to produce a calibrated risk score.

Dependency blast radius

High

How many downstream services depend on this service?

Deploy frequency delta

Medium

Is this change deploying more frequently than historical baseline?

SLO error budget remaining

High

How much error budget is left? Low budget = higher risk.

PR diff size

Medium

Large diffs correlate with higher incident rates.

Time of day / day of week

Medium

Friday 4pm + large diff + low budget = maximum caution.

Recent incident history

High

Services with recent incidents get elevated baseline risk.

Guardrails

Automated enforcement, not just warnings.

Configure what happens at each risk threshold. From advisory notifications to hard blocks: you define the policy, Titan Foresight enforces it.

Advisory

Score 40–69. PR annotation warns the deployer. Deploy proceeds.

Notify + log
Soft block

Score 70–84. Requires second approval or SRE sign-off in the PR.

Require approval
Hard block

Score 85+. Deploy is blocked until risk score drops below threshold.

Block deploy

GitHub integration

Risk score on every PR. No workflow change required.

titan-foresight · PR #847 comment
DT
Titan Foresightjust now

🛡 Risk Analysis · Score: 62/100, Advisory

Analysed 847 lines changed across 3 files.

Blast radius4 downstream services
Error budget38% remaining (caution)
SLO violations (7d)2
RecommendationDeploy off-peak or reduce canary weight

The status quo

How teams assess deploy risk today, and why it fails.

Most teams have no systematic risk model. They rely on gut feel, reviewer experience, and "it worked in staging."

Manual PR review

Senior engineers eyeball every PR for risky patterns. Tribal knowledge determines what gets extra scrutiny.

Failure mode

Doesn't scale. Senior engineers become the bottleneck. Friday PRs get rushed approvals. Blast radius is never quantified.

Staging environment

Run the change in staging for a few hours. If nothing breaks, ship to production.

Failure mode

Staging traffic is synthetic. Dependency graphs differ. 70% of production incidents don't reproduce in staging.

Error budget tracking in dashboards

SREs check Grafana/Datadog before each deploy to see if error budget is healthy. Manual lookup, no automation.

Failure mode

No connection between the dashboard check and the deploy decision. Nothing blocks a high-risk deploy on a depleted budget.

How we compare

Foresight vs. gut feel and DORA dashboards.

CapabilityDeployTitanManual reviewDORA metrics tools
Risk score per PR (automated)✗ (gut feel)
Blast radius mapping
SLO error budget awareness✗ (manual check)~ (reporting only)
Automated deploy guardrails
Analysis time per PR< 2s5–15 minN/A

See a risk score on one of your real PRs.

Connect your GitHub repo, pick a recent PR, and we'll show you the blast radius map, error budget check, and risk score, live in 20 minutes.

Analytics consent

We use optional analytics to improve the site. No tracking unless you accept.