The Product Shelf

If you work with Engineering, sooner or later you’ll hear something like this:

“The service has 99.9% availability.”

Or perhaps:

“We need to get to 99.99%.”

At first glance, the difference seems almost irrelevant. We’re moving from 99.9% to 99.99%. Both are very close to 100%, so how much can that extra nine really matter?

Availability tells us how much of the time a system is expected to be working and accessible. The easiest way to understand those percentages is not to look at the uptime, but at the downtime they allow.

Nines of availability

At 99% availability, a service could be unavailable for around 3.65 days per year. At 99.9%, that falls to about 8.76 hours. With 99.99%, we are talking about roughly 52 minutes, and at 99.999%, just over 5 minutes per year.

That is what Engineering means when they talk about “two nines”, “three nines”, “four nines” or “five nines.”

And once we translate those percentages into downtime, the difference becomes much easier to understand.

Why should a Product Manager care?

Because availability has a direct impact on the product experience.

Imagine that our checkout is unavailable. Users cannot complete their purchases, the business loses revenue and Customer Support starts receiving complaints. If an internal reporting tool is unavailable for the same amount of time on a Sunday morning, the impact might be almost negligible.

Technically, both systems experienced downtime. From a product perspective, however, they are completely different situations.

This is why more availability is not automatically the right product decision.

Achieving another nine usually comes at a price. Engineering may need additional redundancy, better monitoring, failover mechanisms or infrastructure designed to continue operating when individual components fail. The closer we try to get to 100%, the more difficult and expensive that reliability becomes.

So the question shouldn’t simply be:

“Can we achieve 99.99%?”

A much more useful Product question is:

“What level of availability does this product actually need?”

99.9% vs. 99.99%

This is where the trade-off becomes easier to see.

Suppose Engineering tells us we can design a service around two different availability targets:

99.9% → approximately 8.76 hours of downtime per year

99.99% → approximately 52.6 minutes of downtime per year

Four nines is clearly better. Users would potentially experience much less downtime.

But now imagine that reaching four nines requires significantly more engineering work and infrastructure investment.

Is it worth it?

We cannot answer that from the percentages alone. We need to understand what happens when the product is unavailable.

For a payment system processing thousands of transactions every minute, reducing downtime by several hours could have enormous business value. For a feature that customers use occasionally and that can tolerate short interruptions, the same investment might be difficult to justify.

This is where understanding architecture becomes useful for Product Managers. We don’t need to know how Engineering will implement redundancy or failover. We need to understand why those mechanisms might be necessary and what trade-off we are making by investing in them.

Availability is a product decision too

When availability comes up in a technical conversation, try translating the percentage into something tangible.

Instead of discussing whether 99.9% or 99.99% sounds better, ask what that difference means in expected downtime and what would happen during those periods.

How many users could be affected? Can they simply try again later? Are we losing transactions? Is there a manual workaround? Are we breaking a contractual commitment to customers? Could the outage damage trust in the product?

Those questions connect the architecture decision with its real product impact.

So the next time someone says:

“We need four nines of availability.”

You don’t need to know how to build a highly available system.

But you should understand what those four nines mean well enough to ask:

“Why four? What would happen to our users and our business if we had three?”

That’s the part of the conversation where Product has something important to contribute.