# Downtime Calculations and Availability Metrics

### 🔍 What is Downtime vs. Availability?

**Downtime** is the period when your service or system is non-functional, inaccessible, or underperforming. It’s the red zone: incidents, crashes, outages.

**Availability**, on the other hand, is a metric that represents how much time your system remains *available and operational* over a given period.

> **Availability (%) = (Total Time - Downtime) / Total Time × 100**

Or:

> **Availability (%) = Uptime / (Uptime + Downtime) × 100**

📌 **Example**:\
If your system was down for **7.3 hours** in a 30-day month (720 hours total):

> **Availability = (720 - 7.3) / 720 × 100 = 98.99%**

### 🎯 The "Nines" of Availability

It's a shorthand for how little downtime a system is allowed.

| **Availability** | **Yearly Downtime** | **Monthly** | **Weekly** | **Daily** |
| ---------------- | ------------------- | ----------- | ---------- | --------- |
| 90% (One Nine)   | 36.5 days           | 72 hours    | 16.8 hrs   | 2.4 hrs   |
| 99%              | 3.65 days           | 7.2 hours   | 1.68 hrs   | 14.4 mins |
| 99.9%            | 8.76 hours          | 43.8 mins   | 10.1 mins  | 1.44 mins |
| 99.99%           | 52.6 mins           | 4.32 mins   | 1.01 mins  | 8.64 sec  |
| 99.999%          | 5.26 mins           | 25.9 sec    | 6.05 sec   | 0.864 sec |

> 🎓 Each additional 9 increases availability exponentially, but so does the **cost and complexity** of achieving it.

### 📜SLA Downtime Calculations

SLAs define expected availability levels—and thus, permissible downtime.

⏱️ Allowed Downtime

> **Allowed Downtime = Total Time × (1 - SLA %)**

📌 For a 99.99% SLA in a 30-day month:

> **Total Time = 30 × 24 × 60 = 43,200 minutes**\
> **Allowed Downtime = 43,200 × (1 - 0.9999) = 4.32 minutes**

❌ SLA Breach Detection

To check for SLA compliance:

> **Actual Availability = (Total Time - Downtime) / Total Time × 100**

If your availability is **less than SLA**, the SLA is breached—potentially triggering penalties or credits.

#### 📆 Measurement Periods

| **Period** | **Minutes**     |
| ---------- | --------------- |
| Daily      | 1,440 minutes   |
| Weekly     | 10,080 minutes  |
| Monthly    | 43,200 minutes  |
| Yearly     | 525,600 minutes |

### ⚙️ Advanced Metrics: MTBF and MTTR

#### 🔧 MTBF: Mean Time Between Failures

Indicates reliability over time.

> **MTBF = Total Operational Time / Number of Failures**

📌 If a server runs for 1,434 hours and fails twice:

> **MTBF = 717 hours**

### 🏗️ Architecting for High Availability

#### Redundancy Techniques

* ✅ **Multiple Availability Zones** (Cloud)
* ✅ **Failover Load Balancers**
* ✅ **Database Replication**
* ✅ **Redundant Power & Networking**
* ✅ **Auto-healing Infrastructure**

#### Monitoring Architecture Layers

* **Synthetic Monitoring**: Simulated requests
* **Real User Monitoring**: Actual end-user experience
* **Infra Monitoring**: Hardware/VM metrics
* **App Monitoring**: Business KPIs and endpoints

### 🧠 Final Thoughts

Downtime and availability aren't just buzzwords—they're foundational to resilient system design. Whether you're an SRE, architect, or backend engineer, mastering these metrics enables you to:

* Design robust systems
* Set and track SLAs
* Estimate cost impact
* Communicate reliability to stakeholders


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://wisdom.gitbook.io/gyan/system-design/downtime-calculations-and-availability-metrics.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.