Understanding uptime commitments and financial consequences of downtime
A Service Level Agreement (SLA) is a formal commitment between a service provider and customer that defines:
Azure Virtual Machines: Microsoft commits to 99.9% availability for single-instance VMs using Premium SSD or Ultra Disk storage.
Translation: Your VM will be accessible 99.9% of the time. If Microsoft fails to meet this (e.g., only 99.5% uptime), you receive service credits (percentage refund on monthly bill).
Important: SLA credits only cover Azure charges—they don't reimburse your lost revenue from the outage. If your e-commerce site goes down during Black Friday, Azure might refund $500 in credits, but you could lose $50,000 in sales.
SLA percentages sound impressive, but small differences have massive implications for allowed downtime.
| SLA % | Downtime/Year | Downtime/Month | Downtime/Week | Common Use |
|---|---|---|---|---|
| 90% | 36.5 days | 72 hours | 16.8 hours | Unacceptable for production |
| 95% | 18.25 days | 36 hours | 8.4 hours | Dev/test environments only |
| 99% | 3.65 days | 7.2 hours | 1.68 hours | Minimum for non-critical apps |
| 99.5% | 1.83 days | 3.6 hours | 50 minutes | Internal tools, back-office |
| 99.9% (Three 9s) | 8.76 hours | 43.2 minutes | 10 minutes | Standard production target |
| 99.95% | 4.38 hours | 21.6 minutes | 5 minutes | High-availability apps |
| 99.99% (Four 9s) | 52.6 minutes | 4.3 minutes | 1 minute | Business-critical systems |
| 99.999% (Five 9s) | 5.26 minutes | 26 seconds | 6 seconds | Mission-critical (very expensive) |
Key Insight: Moving from 99.9% to 99.99% means reducing allowed downtime from 8.76 hours/year to 52.6 minutes/year—a 10x improvement. This requires significantly more redundancy, failover mechanisms, and multi-region architecture (much higher cost).
| Azure Service | SLA % | Configuration Requirements |
|---|---|---|
| Virtual Machines | 99.9% | Single VM with Premium SSD or Ultra Disk |
| Virtual Machines | 99.95% | 2+ VMs in same Availability Set |
| Virtual Machines | 99.99% | 2+ VMs across 2+ Availability Zones |
| App Service | 99.95% | Standard tier or higher |
| Azure SQL Database | 99.99% | General Purpose, Business Critical, or Hyperscale |
| Azure Cosmos DB | 99.999% | Multi-region writes enabled (read/write SLA) |
| Storage (LRS) | 99.9% | Locally Redundant Storage (LRS) |
| Storage (GRS) | 99.99% | Geo-Redundant Storage (GRS) - read access |
| Azure Kubernetes (AKS) | 99.95% | Uptime SLA enabled (paid add-on) |
| Functions (Premium) | 99.95% | Premium plan with availability zones |
If Azure fails to meet the SLA commitment, you receive service credits (refund as percentage of monthly charges for the affected service).
| Actual Uptime | Service Credit |
|---|---|
| < 99.9% | 10% of monthly bill |
| < 99% | 25% of monthly bill |
| < 95% | 100% of monthly bill |
This is a hypothetical, illustrative example for teaching purposes, not an actual case study.
Your VMs: $5,000/month Azure bill
Outage: 2-hour unplanned downtime (99.7% uptime for the month)
SLA Missed: Below 99.9% threshold
Credit: 10% × $5,000 = $500 service credit
The Hidden Problem: That 2-hour outage cost you $50,000 in lost revenue (e-commerce site down during peak sales). Azure gives you $500 credit, but your business lost 100x more. SLA credits don't cover business impact—only Azure charges.
SLA credits are nice, but they pale compared to actual business losses.
This is a hypothetical, illustrative example for teaching purposes, not an actual case study.
Revenue: $10M/year ($1,142/hour)
1-hour outage: ~$1,142 direct revenue loss
+ Customer churn impact
Total: $5K-$10K loss
ARR: $50M, 5,000 customers
4-hour outage: Productivity loss for customers
Churn risk: 1-2% dissatisfied customers
Total: $500K-$1M (annual churn)
Operations: High-frequency trading
15-minute outage: Missed trading opportunities
Regulatory impact: Fines possible
Total: $100K-$500K
Formula: Annual Downtime Cost = (Annual Revenue ÷ 8,760 hours) × Hours Downtime × Impact Multiplier (1.5-3x for churn/reputation)
Your application's SLA is not the SLA of a single service—it's the product of all dependent services.
Components:
• Azure App Service (web): 99.95%
• Azure SQL Database: 99.99%
• Azure Storage: 99.9%
Composite SLA Calculation:
0.9995 × 0.9999 × 0.999 = 0.9984 = 99.84%
Result: Even though each individual service has excellent SLA (99.9%+), your application SLA drops to 99.84%—about 14 hours of allowed downtime per year.
This is why microservices architectures need robust retry logic, circuit breakers, and redundancy.
Trade-off: Each tier doubles complexity and increases cost ~50-100%.
Key: RTO (Recovery Time Objective) determines failover speed needed.
Pro tip: Application-level resilience often more cost-effective than infrastructure redundancy.
| Target SLA | Architecture | Relative Cost | When to Use |
|---|---|---|---|
| 99% | Single instance | 1x (baseline) | Dev/test, internal tools |
| 99.9% | Availability Set | 1.5x | Standard production apps |
| 99.95% | Availability Zones | 2-2.5x | Customer-facing apps, e-commerce |
| 99.99% | Multi-region active-passive | 3-4x | Business-critical, high revenue impact |
| 99.999% | Multi-region active-active | 5-10x | Mission-critical (finance, healthcare) |
The Law of Diminishing Returns: Moving from 99% to 99.9% is relatively cheap (1.5x cost). But 99.99% to 99.999% costs 2-3x MORE for only 10x less downtime. Always do the math: is the business impact of that extra downtime worth the cost?
Direct SLA Impact:
Reduce Self-Inflicted Outages:
Balance SLA vs. Cost:
SLAs are where architecture meets business impact:
Career Impact: When proposing architecture, speak in SLA business terms: "Multi-region failover increases SLA from 99.9% to 99.99%—reducing annual downtime from 8.76 hours to 52 minutes. Based on $1,142/hour revenue, this prevents $9K in annual losses for $15K additional infrastructure cost. ROI: −40% (a net loss on paper), payback: 20 months." Even though the direct ROI here is negative—you're spending $15K to prevent $9K—the reliability improvement may still be worth it for reasons a pure ROI calculation doesn't capture: reduced risk of a reputation-damaging outage, career credibility, and customer trust. Just don't misrepresent the math to justify it; say plainly that the payback is on intangibles, not the spreadsheet. You've just translated technical decisions into CFO language, negative ROI and all.
Continue your learning journey