How Much Reliability Does Each of Your Systems Need?

When one uptime goal covers everything a company runs, the checkout that takes payments and the report that runs overnight are held to the same number and given the same level of backup infrastructure.

Those two systems carry very different risk. A delayed overnight report costs the business little, so the backup capacity bought for it protects against a small loss.

Checkout loses revenue every minute it is offline, and because it runs through several services, it can fall below the shared goal even when each service meets it.

In my view, the target belongs to the business flow, measured from the first service it touches to the last. The downtime that flow is allowed should be set by what an hour offline costs the business, which makes it a decision for business leaders as much as for engineers.

Engineers call this allowance an error budget, and it does two jobs. It shows how much redundancy is worth paying for. It also works as a monthly limit, so when a flow has used its allowed minutes, new releases wait until it is stable again.

One 99.9% goal overpays for reporting and falls short on checkout

A 99.9% goal sounds like a safe middle choice until you follow it through the overnight report and checkout.

What the research found

Microsoft’s example tiers attach an architecture to each target. A system that can be down for about 7 hours a month runs in a single region. One held to 99.9% is allowed 43 minutes and needs a second region kept on standby.

The overnight report could live with the 7 hours. Held to 99.9%, it gets a standby region that the business pays for every month and may never use.

Checkout has the opposite problem. It relies on several services, and each can fail on its own, so their downtime adds up. Microsoft’s example uses an app rated at 99.99%, a database at 99.95%, and a cache at 99.9%, so each meets or beats the goal individually.

Together they allow roughly 69 minutes of downtime a month, well past the 43 minutes the goal permits.

What this means for you

For systems like the report, this is a saving. Anything that could tolerate hours of downtime can move to a lower target, and the standby capacity behind it is spend you can recover.

For flows like checkout, it is a risk you can measure now. Add up the allowed downtime for every service your highest-revenue flow depends on. If the total exceeds what your goal permits, you can strengthen the weakest service or lower the figure you promise the business.

What an hour of downtime costs decides the tier

Teams often make tier decisions on technical grounds and defend them to finance afterward. Microsoft’s reliability guidance reverses the order. Business stakeholders weigh the revenue lost to downtime against the cost of designing and operating the flow, and then decide whether more reliability is worth buying.

Microsoft’s criticality ratings turn that into a sorting rule. A flow whose failure reaches customers or payments straight away belongs in the high tier, and one that can be retried without anyone outside noticing sits in the middle.

Where disruption causes no significant immediate problem, as with a nightly log transfer, the low tier is enough.

When a single-region design is enough

Even a high rating leaves design choices. Microsoft’s mission-critical guidance says a single region with multiple zones may suffice for many critical workloads, and it advises against defaulting to active-active across regions.

Its reliability guidance adds a second test, which is whether your staffing can support a constant on-call rotation.

Two illustrative cases show both tests at work. Payroll feels critical, yet it runs twice a month, so a low tier is enough if recovery is assured before the next pay run.

A customer API under a contractual SLA earns a high target, but a firm with one on-call engineer fails the staffing test, so it runs in one region across zones and buys round-the-clock coverage as a managed service.

The downtime allowance should also decide when releases pause

Once you pay for the right architecture, it is tempting to treat reliability as bought. The architecture sets how much downtime a system can absorb, while what your teams release decides whether a flow stays inside its allowance.

What the research found

In Uptime Institute’s 2026 outage analysis, 87% of operators with a recent impactful outage said it could have been avoided with better management, processes, or configuration.

The survey covers data center operators, so I read it narrowly as evidence that outages often start with how systems are run.

That is why I would let the allowance decide when releases go ahead, through one rule that product and operations share.

While a flow has allowance left for the month, releases continue. Once it is used up, new releases wait while the team fixes what caused the downtime, with urgent security fixes as the standing exception.

The pause is my own recommendation, and it puts a number on the stability guardrail I described when measuring the return on AI-assisted development.

Case in point

A pause works only if teams set aside time for stability work. At the insurer Allianz Direct, the business agreed that every squad would spend 20% of its time on operations, as its platform lead told at a conference. That prior agreement is the part worth copying, because a pause has little value unless the business has already accepted the time it takes.

Every target needs an owner and a review date

A target set today can be wrong within a year, because a flow that was minor when it was tiered may be carrying revenue by then. Microsoft’s guidance gives each flow a named owner and asks you to review its criticality periodically.

I would tie that review to annual planning and change the tier when the flow’s revenue or dependencies have changed. Between reviews, the owner should track how many minutes of allowance the flow used and how many of those came from your own changes.

Microsoft adds that a flow whose recovery has never been tested should not carry a guaranteed uptime commitment.

From the field

When we began working with a US investment firm, its Azure environment had been inherited from earlier vendors, and several attempts at a disaster recovery plan had failed. Recovery targets could be set only after we mapped the environment and ranked each workload by how much the business depended on it.

Those targets are now tested in an isolated copy of production, and failover simulations run 60% faster, making regular testing practical.

Downtime targets change what you measure a partner on

All of this fits on one sheet, with each flow listed beside its cost per hour offline, tier, monthly allowance, owner, last recovery test, and review date. Finance and engineering can then discuss reliability in the same terms, minutes of downtime and what they cost.

The sheet is just as useful with the partners who run those systems for you. A managed services provider is often judged on how quickly it responds to a ticket, which says little about whether checkout stayed within its allowance.

For that reason, Simform’s cloud managed services team, which holds Microsoft’s Azure Expert MSP designation, scopes its commitments by workload criticality. Asking any partner for a report against each flow’s allowance moves the review to the result you are paying for.

Worth your time this week

If you lead data or AI at a healthcare organization, join Simform’s Ritesh Shah and Microsoft’s Chase Dixon on October 15 for Turning Unified Patient Data into Actionable Clinical Intelligence. The session covers six decisions that shape that work. It runs from 9 to 10 AM PT, 12 to 1 PM ET.