A founder is reviewing a cloud provider proposal. It promises '99.99% uptime, ' a 'P99 latency SLO of 200ms,' and 'MTTR under 15 minutes.' They nod along, sign the contract, and have no idea what they just agreed to. Cloud infrastructure proposals are full of terms that sound technical but have very specific, measurable meanings — and misunderstanding them can leave businesses exposed when things go wrong. These aren't developer terms. They're business terms. Uptime is revenue protection. Latency is user experience. SLAs are legal commitments. Understanding them makes you a sharper buyer and a better partner for your tech team.

This post decodes the cloud terms you'll encounter most often — in plain English, with real business context for each one.

The Master Glossary — 12 Terms Defined

Before we go deeper on the most important concepts, here's a reference table covering every term you're likely to encounter when evaluating cloud infrastructure or reviewing vendor contracts:

Uptime — What the Percentages Actually Mean

Your provider promises 99.9% uptime. Sounds excellent. But what does that translate to in real downtime hours?

Industry shorthand calls 99.9% 'three nines,' 99.99% 'four nines,' 99.999% 'five nines.' The difference between three and four nines is 8+ hours of downtime per year — significant for revenue-generating products. A monthly SLA of 99.9% allows ~44 minutes of downtime per month. If an outage happens during your busiest period — a product launch, end-of-month billing, a sale campaign — that 44 minutes could cost more than a full month's infrastructure bill. Scheduled maintenance windows are often excluded from SLA calculations. Ask vendors to define what counts as 'downtime' before signing.

Latency — The Performance Metric That Drives User Behaviour

latency is the time between a user taking an action - clicking a button, loading a page, submitting a form — and the app responding. It's measured in milliseconds (ms). Users don't consciously notice 100ms delays, but their behaviour changes. Bounce rates, session length, and conversion rates are all measurably affected by latency.

latency is typically reported as a percentile, not an average. 'P99 latency of 300ms' means 99% of requests are answered within 300ms — but 1% take longer, potentially much longer. For a product with 10,000 daily users, that's 100 people getting a slow experience every day.

Cover the main causes of high latency:

• Geographic distance between users and servers (solved by CDNs and multi-region deployment)
• Database query inefficiency (solved by indexing, caching, query optimisation)
• Network congestion or provider infrastructure quality
• Unoptimised API calls or waterfalled requests in the application code

Modern cloud providers offer global edge networks, CDNs, and managed caching layers specifically to reduce latency for users regardless of geography. This is a solved problem — if the infrastructure is designed correctly.

Let's consider an analogy: think of a restaurant. The menu promises 'food served within 20 minutes' — that's the SLA (the external commitment). The kitchen has an internal target of 15 minutes — that's the SLO (the internal goal). The timer tracking each order is the SLI (the measurement).

SLA (Service Level Agreement):

The formal, contractual commitment your vendor makes to you — or that you make to your clients. Breach triggers penalties: service credits, refunds, or contract termination rights. This is the floor.

SLO (Service Level Objective):

The internal target a team sets for itself, typically more ambitious than the SLA. If the SLA promises 99.9% uptime, the SLO might be 99.95%. The gap between SLO and SLA is the error budget.

SLI (Service Level Indicator):

The actual measured metric — the real data that tells you whether the SLO and SLA are being met. Examples: request success rate, response time percentiles, error rate per hour.

SLI (Service Level Indicator):

The actual measured metric — the real data that tells you whether the SLO and SLA are being met. Examples: request success rate, response time percentiles, error rate per hour.

When evaluating vendors, ask for their SLIs and SLOs, not just their SLAs. A vendor who publishes real-time SLI dashboards is confident in their service. One who only offers SLA language in a contract may not be. Your clients deserve SLAs backed by real SLOs and SLI monitoring. Without all three, an SLA is a legal document with no operational substance behind it.

The Recovery Metrics — MTTR, MTBF, RTO, and RPO

Uptime tells you how often a system is available. Recovery metrics tell you what happens when it isn't — how quickly does it recover, and how much is lost?

MTTR (Mean Time To Recovery):

The average time to restore service after an incident begins. Lower is better. An MTTR of 4 hours means the average outage lasts 4 hours. Cloud automation — self-healing infrastructure, automated rollbacks, on-call alerting — directly reduces MTTR.

MTBF (Mean Time Between Failures):

How frequently incidents tend to occur on average. Higher is better. A system with a MTBF of 180 days fails roughly twice a year. Infrastructure maturity, testing rigour, and change management directly affect this.

RTO (Recovery Time Objective):

The maximum acceptable time to restore service after a failure — what your business can tolerate. If your RTO is 1 hour, your infrastructure and incident response process must be designed to meet that. Your RTO drives your architecture decisions.

RPO (Recovery Point Objective):

The maximum acceptable data loss measured in time. An RPO of 15 minutes means you must have backups no more than 15 minutes apart. For financial or health data, RPO is often measured in seconds.

SLA Red Flags — What to Watch for in Vendor Contracts

Not all SLAs are created equal. Here are the most common ways cloud vendors write commitments that look strong on the surface but offer minimal protection in practice:

The most reliable signal of a vendor's confidence is whether they publish real-time status pages and historical uptime data. If the data is public, they have an incentive to keep it good. If it's buried in a contract, ask yourself why.

Does Your Product Have These Commitments in Place?

• What is our current measured uptime over the last 90 days?
• What is our P95 and P99 latency for our most critical user flows?
• Do we have a documented SLA with our infrastructure provider — and have we read it?
• Do we have internal SLOs that our engineering team is actively monitoring?
• What is our actual MTTR based on the last three incidents?
• Do we have a defined RTO and RPO — and is our backup strategy aligned to the RPO?
• Do we have a real-time monitoring and alerting system, or do users tell us when things break?

Conclusion

These aren't developer terms — they're business terms. Uptime is revenue protection. Latency is user retention. SLAs are the contracts that define accountability when things go wrong.

You now have the vocabulary to read a vendor proposal intelligently, ask the right questions in a sales call, and hold your infrastructure partners accountable to commitments that actually mean something.

Building and operating cloud infrastructure to these standards - designing for 99.99% uptime, monitoring real SLIs, running with documented RTO and RPO targets - is what separates professional infrastructure work from amateur hosting.'