Business case

An outage number nobody argues with still needs a pitch.

A credible annual cost figure is necessary but not sufficient. This page is a framework for turning that number into a budget conversation that actually gets approved.

reliability investment business case downtime cost budget justification SRE budget pitch uptime ROI framework
Read the framework Get your number first
Scroll for the framework
3 Numbers a budget conversation actually needs
1 Objection that kills most reliability pitches
The framework

Three numbers, not one.

A single "downtime costs us $X per year" figure invites debate about the model. Three connected numbers invite a decision instead.

1. Current annual exposure Your calculated annual cost using your own systems, revenue impact, MTTR, frequency, and SLA target — the baseline everything else compares against. Cite the formula so the number is auditable, not asserted.
2. Exposure after the proposed investment Re-run the same calculator with the MTTR or frequency you'd expect after the investment — a faster on-call rotation, redundant infrastructure, or a monitoring upgrade each map to a specific input change, not a vague "improved reliability" claim.
3. The delta versus the ask Annual savings (number 1 minus number 2) compared directly against the cost of the investment — a project that pays for itself inside one avoided incident is a fundamentally different conversation than one that doesn't.
Handling pushback

The model will get challenged. Plan for it.

A finance stakeholder's job is to stress-test assumptions — treat the pushback as part of the process, not a sign the case is weak.

01

"Your hidden cost multiplier looks made up"

Show the formula directly and offer to remove it entirely for a conservative version of the case — if the direct-loss number alone still justifies the investment, you've made a stronger case, not a weaker one.

02

"We haven't had an outage that bad"

Point to the case studies of real, well-documented incidents at comparable companies — the absence of a bad outage so far is evidence of luck or under-reporting, not evidence of low risk.

03

"This is an infrastructure problem, not a budget problem"

Reframe explicitly: infrastructure decisions are budget decisions with a delay built in — the same dollars get spent either way, just as a planned investment now or an unplanned incident cost later.

FAQ

Building the case, answered.

Questions that come up when preparing this for a budget review or board update.

Who should this pitch be aimed at? Whoever controls the budget for the investment — usually finance or an engineering leadership committee — not the technical team that will implement it, who typically don't need convincing.
Should I present a single number or a range? Present a range with your point estimate in the middle — a range signals that you understand the model's sensitivity, which builds more credibility than false precision on a single figure.
What if the numbers don't clearly justify the investment? Say so — a transparent case that doesn't fully justify the ask is more credible long-term than an inflated one, and you can pair it with a smaller, cheaper first step instead.
How specific should the "after" scenario be? As specific as the investment itself — see scenario planning for worked examples of how a specific MTTR or frequency change flows through to a new annual cost figure.
Your turn

Start with your current exposure.

Get your baseline number, then model the investment's effect on it.

Open the calculator See scenario examples

Mode

Accent