# Grafana Cloud
All Grafana Cloud notes →Chapter 1 — Grafana SLO
Defining SLIs and SLOs, tracking error budgets, and configuring burn-rate alerts and reliability reporting in Grafana Cloud's SLO app.
Chapter 2 — Grafana Incident
Incident lifecycle, timeline, collaboration, runbooks, and postmortems in Grafana Incident.
Chapter 3 — Grafana OnCall
Escalation policies, on-call schedules, alert routing, and integrations in Grafana OnCall.
Chapter 4 — Incident Response & Management (IRM)
Incident coordination, response automation, analytics, and operational workflows in Grafana IRM.
# Sre
All Sre notes →1 — Reliability Principles
The handful of first-principles ideas — redundancy, graceful degradation, known failure modes — that every other chapter in this Part is a specific application of.
10 — Failure Domains
Drawing the boundary around 'what breaks together' — AZ, region, tenant, deploy group — so a single fault has a bounded, known blast radius instead of an open-ended one.
11 — Redundancy Patterns
Active-active, active-passive, and N+1 redundancy, and the trade-off each makes between failover speed, cost, and the complexity of keeping replicas actually consistent.
12 — Graceful Degradation
Designing a system to shed non-critical functionality under stress instead of failing completely — and deciding in advance what's non-critical.
13 — Backpressure
The signal a slow consumer sends a fast producer to prevent unbounded queue growth, and why a system without backpressure fails by silently falling further behind until it doesn't.
14 — Queue Management
Queue depth as a leading indicator of saturation, and the policies — bounded queues, priority lanes, dead-letter handling — that keep a backlog from becoming the outage.
15 — Load Shedding
Deliberately rejecting a fraction of requests to protect the system's ability to serve the rest, and the prioritization logic that decides which fraction.
16 — Circuit Breakers
Failing fast instead of piling up timeouts against a dependency that's already down, and the half-open state that decides when it's safe to try again.
17 — Retry Strategies
Exponential backoff and jitter as the difference between a retry storm that takes down a recovering dependency and one that lets it heal.
18 — Timeouts
Why every network call needs an explicit timeout budget, and how an unset or mismatched timeout turns one slow dependency into a resource leak upstream.
19 — Bulkheads
Partitioning resources — thread pools, connection pools — per dependency so one slow downstream can't exhaust the resources every other call path also needs.
2 — Service Level Indicators (SLIs)
Picking the metric that actually reflects user-perceived reliability, and why the wrong SLI makes every SLO built on top of it meaningless.
20 — Idempotency
Designing an operation so a retry is safe by construction, which is what actually makes retries, at-least-once delivery, and failover recoverable instead of dangerous.
3 — Service Level Objectives (SLOs)
Turning an SLI into a target with a time window, and why the window you choose changes what 'reliable' even means operationally.
4 — Error Budgets
The spendable resource an SLO creates, and how a burned error budget becomes an organizational decision — freezing launches — instead of just another alert.
5 — Availability Engineering
What 'three nines' actually costs to achieve, and why each additional nine is an order-of-magnitude harder engineering and financial commitment than the last.
6 — Latency Engineering
Why tail latency (p99, p99.9), not the average, is what determines whether users actually experience a service as fast.
7 — Capacity Planning
Forecasting demand ahead of the traffic that would otherwise turn a capacity gap into an incident, and the headroom math that makes the forecast survivable.
8 — Scalability Engineering
Designing a system so growth is a capacity-planning exercise, not a rewrite — and knowing which scaling axis (vertical, horizontal, functional) actually fixes the bottleneck you have.
9 — Reliability Modeling
Quantifying failure probability across a system's dependency graph before it fails, using the same math that predicts hardware MTBF applied to services.