79:T495,### 3. Throughput SLI **Definition:** The rate at which the system processes requests. ``` Throughput SLI = Requests processed per second (or minute/hour) ``` **When throughput matters as an SLI:** - **Ingestion systems:** Must keep up with incoming data rate - **Batch processing:** Must complete within time windows - **Rate-limited APIs:** Must honor contracted request quotas **Throughput vs. Capacity:** Throughput SLIs measure actual work done. Capacity is the theoretical maximum. Your SLI should reflect that you can sustain *expected* throughput, not just peak. ### 4. Error Rate SLI (Error Classification) **Definition:** The proportion of requests that fail, often broken down by error type. ``` Error Rate SLI = (Failed Requests / Total Requests) × 100% ``` **Why classify errors?** Not all errors are created equal: - **Retriable errors (503, timeout):** Frustrating but recoverable - **Business logic errors (400, 422):** Might be client issues - **Critical errors (500, data corruption):** Require immediate attention - **Dependency errors:** Your service is fine, downstream is broken Separate SLIs for error classes enable targeted responses.7a:T43d,from prometheus_client import Counter, Histogram import time # SLI: Request success rate request_total = Counter( 'http_requests_total', 'Total HTTP requests', ['method', 'endpoint', 'status_class'] ) # SLI: Request latency request_latency = Histogram( 'http_request_duration_seconds', 'HTTP request latency', ['method', 'endpoint'], buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0] ) def handle_request(request): start_time = time.time() try: response = process_request(request) status_class = '2xx' if 200 <= response.status < 300 else '4xx' return response except Exception as e: status_class = '5xx' raise finally: # Always record metrics duration = time.time() - start_time request_latency.labels( method=request.method, endpoint=request.path_template ).observe(duration) request_total.labels( method=request.method, endpoint=request.path_template, status_class=status_class ).inc()7b:T4db,import { Counter, Histogram, Registry } from 'prom-client'; const register = new Registry(); // SLI: Request success rate const requestTotal = new Counter({ name: 'http_requests_total', help: 'Total HTTP requests', labelNames: ['method', 'endpoint', 'status_class'], registers: [register], }); // SLI: Request latency (with percentile-friendly buckets) const requestLatency = new Histogram({ name: 'http_request_duration_seconds', help: 'HTTP request latency', labelNames: ['method', 'endpoint'], buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0], registers: [register], }); export async function handleRequest( request: Request, handler: () => Promise ): Promise { const startTime = Date.now(); let statusClass = '5xx'; try { const response = await handler(); statusClass = response.status < 400 ? '2xx' : '4xx'; return response; } finally { const duration = (Date.now() - startTime) / 1000; requestLatency .labels({ method: request.method, endpoint: getPathTemplate(request) }) .observe(duration); requestTotal .labels({ method: request.method, endpoint: getPathTemplate(request), status_class: statusClass }) .inc(); } }7c:T481,### 2. Load Balancer/Edge Metrics **How it works:** Your load balancer or API gateway records metrics for every request passing through. **Pros:** - Captures all traffic, including requests that crash your application - Includes time spent in load balancing/routing - Consistent measurement across all backends - No application code changes required **Cons:** - Less contextual information than application metrics - Still doesn't capture client-side experience - May require log processing rather than real-time metrics **Best for:** Public-facing APIs, multi-service architectures ### 3. Client-Side/Real User Monitoring (RUM) **How it works:** JavaScript or mobile SDK measures actual user experience in-browser/in-app. **Pros:** - Truest representation of user experience - Captures network latency, DNS resolution, rendering time - Detects issues invisible to server-side metrics **Cons:** - More complex to implement - Sampling often required for high-traffic sites - Privacy considerations with user data - Can't rely on client-side data for alerting (delayed, unreliable delivery) **Best for:** User-facing web applications, mobile apps7d:T572,### Streaming Video Service SLIs **Critical User Journeys:** - Browse catalog → Select content - Start playback → Watch without interruption - Search → Find content quickly **SLI Definitions:** 1. **Playback Start Time:** % of playback requests starting in < 2 seconds 2. **Rebuffering Ratio:** % of playback time without rebuffering events 3. **Catalog Availability:** % of catalog API requests succeeding 4. **Content Availability:** % of content library accessible (not geo-blocked, not broken links) 5. **Video Quality Stability:** % of sessions maintaining 1080p or higher **Why these matter:** User engagement is extremely sensitive to playback quality. A rebuffer drives users to competitors. ### Banking API SLIs **Critical User Journeys:** - Login authentication - Balance inquiry - Fund transfer - Transaction history **SLI Definitions:** 1. **Authentication Success Rate:** % of login attempts completing successfully (excluding invalid credentials) 2. **Transaction Integrity:** % of transfers where amount debited equals amount credited 3. **API Latency:** % of API calls completing in < 100ms 4. **Data Consistency:** % of balance queries returning data < 1 second stale 5. **Availability During Business Hours:** % uptime during 6 AM - 10 PM local time **Why these matter:** Financial systems have regulatory requirements and zero tolerance for data inconsistency.71:{"json":{"id":"seed_9fd9d3c697e44fabc764467a0e7c990d","slug":"slis-slos-and-slas","category":"System Design (HLD)","topic":"SLOs, SLIs & Incident Management","title":"SLIs, SLOs, and SLAs","description":"Master the trinity of reliability engineering: Service Level Indicators (SLIs), Service Level Objectives (SLOs), and Service Level Agreements (SLAs). Understand how to measure, target, and contractually commit to reliability in distributed systems.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_746779c838b20fa0ac7978eef8b90896","title":"SLI: Service Level Indicator","order":0,"content":[{"id":"opening-hook","title":"The Foundation of Measurable Reliability","content":[{"data":{"content":"In the world of distributed systems, opinions about reliability are worthless without data. Engineers often argue about whether a service is 'fast enough' or 'reliable enough,' but these debates remain subjective until we establish **objective, quantitative measurements**. This is precisely where Service Level Indicators (SLIs) transform reliability from an art into a science.\n\n**Service Level Indicators are the quantitative measures that objectively capture the health and behavior of your service from the user's perspective.** They are not arbitrary metrics chosen for convenience—they are carefully selected measurements that directly correlate with user happiness and business outcomes."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand what SLIs are, why they matter profoundly for reliability engineering, and how to select and implement SLIs that truly represent your users' experience. You'll learn to distinguish good SLIs from vanity metrics, and master the art of measurement that drives all subsequent reliability decisions.","variant":"info"},"type":"callout"}]},{"id":"what-is-sli","title":"What is a Service Level Indicator?","content":[{"data":{"content":"A **Service Level Indicator (SLI)** is a carefully defined quantitative measure of some aspect of the level of service being provided. In simpler terms, it's a metric that tells you how well your service is performing from the perspective of its users or consumers.\n\nThe key word here is *quantitative*. An SLI must be:\n\n- **Measurable**: It can be expressed as a number\n- **Objective**: Different observers measuring the same thing get the same result\n- **User-centric**: It reflects something users actually care about\n- **Actionable**: When it degrades, you can do something about it"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The SLI Definition Formula","content":"An SLI is typically expressed as a ratio:\n\n**SLI = (Good events / Total events) × 100%**\n\nFor example, an availability SLI might be:\n\n**(Successful requests / Total requests) × 100%**\n\nThis ratio format is crucial—it normalizes the metric regardless of traffic volume and makes it directly comparable across time periods.","variant":"tip"},"type":"callout"},{"data":{"content":"### The Critical Distinction: SLIs vs General Metrics\n\nNot every metric qualifies as an SLI. Consider the difference:\n\n**Metrics that are NOT good SLIs:**\n- CPU utilization (users don't care about your CPU)\n- Memory consumption (internal implementation detail)\n- Queue depth (proxy measure, not direct user experience)\n- Server count (infrastructure concern)\n\n**Metrics that ARE good SLIs:**\n- Request success rate (users directly experience failures)\n- Request latency (users wait for responses)\n- Data freshness (users see stale or current data)\n- Throughput (users get blocked when capacity is exceeded)"},"type":"text"},{"data":{"rows":[["Request success rate","99.5% of requests return 2xx","Direct - users see errors","✅ Excellent"],["P99 latency","95% of requests complete in <200ms","Direct - users experience delays","✅ Excellent"],["CPU utilization","Average 65% across fleet","Indirect - may not affect users","❌ Poor"],["Disk I/O","500 IOPS sustained","Indirect - internal concern","❌ Poor"],["Data freshness","99% of reads are <1 min stale","Direct - users see outdated data","✅ Good"],["Error rate by type","0.1% timeouts, 0.05% 500s","Direct - different failure modes","✅ Good"]],"caption":"SLI Candidates vs Internal Metrics","headers":["Metric Type","Example","User Impact","Good SLI?"]},"type":"table"}],"titleType":"number","titleNumber":1},{"id":"why-slis-matter","title":"Why SLIs Are Foundational to Reliability Engineering","content":[{"data":{"content":"SLIs aren't just nice-to-have metrics—they are the **foundation upon which all reliability engineering is built**. Without well-defined SLIs, you cannot:\n\n1. **Set meaningful objectives** - SLOs are literally built on SLIs\n2. **Create effective alerting** - What do you alert on if you don't know what matters?\n3. **Prioritize engineering work** - How do you justify reliability investments?\n4. **Communicate with stakeholders** - What's your answer when the CEO asks 'Is the service reliable?'\n5. **Conduct meaningful postmortems** - You need quantitative measures of impact"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Cost of Poor SLI Selection","content":"Teams that choose poor SLIs often find themselves in frustrating situations:\n\n• Alerts fire but users are happy (false positives waste engineering time)\n• Users complain but dashboards show green (false negatives destroy trust)\n• Engineering debates become political rather than data-driven\n• Reliability investments are seen as cost centers rather than strategic\n\nThe root cause is almost always measuring the wrong things—internal metrics instead of user-facing indicators.","variant":"warning"},"type":"callout"},{"data":{"content":"### The User Happiness Hypothesis\n\nThe core philosophy behind SLIs is what Google's SRE team calls the **user happiness hypothesis**:\n\n> *If you measure something that genuinely reflects user experience, and that measure is good, then your users are probably happy. If it's bad, they're probably unhappy.*\n\nThis seems obvious, but it's surprisingly difficult to achieve in practice. Many organizations measure what's easy to collect (CPU, memory, disk) rather than what actually matters (success rate, latency, correctness).\n\n**The hierarchy of measurement quality:**\n\n1. **Best**: Measure at the user's device (true user experience)\n2. **Good**: Measure at the edge/load balancer (close to user)\n3. **Acceptable**: Measure at the application server (includes internal processing)\n4. **Poor**: Measure internal resources (CPU, memory, queues)\n\nThe closer you measure to the actual user experience, the more meaningful your SLI becomes."},"type":"text"},{"data":{"items":["**Objective Decision Making** — Reliability discussions shift from opinions to data. 'I think the service is slow' becomes 'P99 latency degraded from 120ms to 340ms.'","**Clear Prioritization** — When you can quantify impact ('This fix will recover 0.3% of our error budget'), prioritization becomes straightforward.","**Aligned Incentives** — Product, engineering, and operations teams share a common definition of 'good' based on measurable user impact.","**Historical Trending** — Quantitative SLIs enable trend analysis. You can detect slow degradation before it becomes catastrophic.","**Comparative Analysis** — Compare reliability across services, teams, or time periods using a common vocabulary."],"title":{"icon":"Target","text":"Benefits of Well-Defined SLIs","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":2},{"id":"four-golden-slis","title":"The Four Golden SLIs","content":[{"data":{"content":"While every service is unique, most services can be characterized by a common set of SLI categories. Google's SRE book popularized what are now known as the **Four Golden Signals**, which translate directly into SLI categories:\n\n**1. Availability (Success Rate)**\n**2. Latency (Response Time)**\n**3. Throughput (Request Rate)**\n**4. Error Rate (Failure Classification)**\n\nFor most request-driven services, you'll want SLIs covering at least the first two categories. Let's examine each in depth."},"type":"text"},{"data":{"icon":"Info","title":"SLIs for Different Service Types","content":"Not all services are request-driven. For pipeline/batch systems, you might measure:\n• **Freshness** — How recently was the data processed?\n• **Throughput** — How many records processed per hour?\n• **Correctness** — What percentage of outputs are verified correct?\n\nFor storage systems:\n• **Durability** — Probability that stored data can be retrieved\n• **Availability** — Percentage of time the storage responds\n• **Latency** — Time to read/write data","variant":"note"},"type":"callout"},{"data":{"content":"### 1. Availability SLI\n\n**Definition:** The proportion of requests that are served successfully.\n\n```\nAvailability SLI = (Successful Requests / Total Requests) × 100%\n```\n\n**What counts as 'successful'?**\n\nThis is where precision matters. Consider these scenarios:\n\n- HTTP 200 OK — Clearly successful\n- HTTP 404 Not Found — Is this a server error or valid 'resource doesn't exist'?\n- HTTP 400 Bad Request — Client's fault, not server failure\n- HTTP 500 Internal Server Error — Server failure, not successful\n- HTTP 503 Service Unavailable — Server overloaded, not successful\n\n**Best Practice:** Define success as 'the server processed the request correctly, regardless of the business outcome.' A 404 for a genuinely missing resource is successful processing. A 404 caused by a routing bug is not."},"type":"text"},{"data":{"content":"### 2. Latency SLI\n\n**Definition:** The proportion of requests served faster than a threshold.\n\n```\nLatency SLI = (Requests faster than threshold / Total Requests) × 100%\n```\n\n**Why percentiles, not averages?**\n\nAverages hide problems. Consider two scenarios:\n\n- **Scenario A:** 90% of requests at 100ms, 10% at 200ms → Average: 110ms\n- **Scenario B:** 90% of requests at 100ms, 10% at 1100ms → Average: 200ms\n\nThe averages (110ms vs 200ms) seem similar, but Scenario B has 10% of users waiting 11x longer! Percentiles reveal this.\n\n**Common latency percentiles:**\n- **P50 (median):** The 'typical' experience\n- **P90:** 90% of requests are faster than this\n- **P99:** Only 1% of requests are slower\n- **P99.9:** The long tail, often critical for enterprise customers"},"type":"text"},{"data":{"rows":[["P50","Typical user experience","General performance baseline"],["P90","Experience for 'slower' requests","Capacity planning"],["P99","Worst case for most users","SLO targets for latency-sensitive services"],["P99.9","Extreme tail latency","Enterprise customers, SLA enforcement"],["Max","Absolute worst case","Debugging, rarely for SLIs (too noisy)"]],"caption":"Latency Percentiles: What They Reveal","headers":["Percentile","What It Tells You","When to Use"]},"type":"table"},{"data":{"content":"$79"},"type":"text"}],"titleType":"number","titleNumber":3},{"id":"selecting-slis","title":"Selecting the Right SLIs for Your Service","content":[{"data":{"content":"Selecting SLIs is both an art and a science. You need enough SLIs to capture user experience comprehensively, but not so many that they become unmanageable. Here's a systematic approach:"},"type":"text"},{"data":{"type":"ordered","items":["**Identify your users** — Who consumes your service? End users via web/mobile? Other services via API? Batch jobs?","**Map user journeys** — What are the critical paths? Login → Browse → Purchase? Or Query → Process → Store?","**Define 'good' vs 'bad'** — For each journey, what constitutes success? What makes users unhappy?","**Choose measurable proxies** — What metrics best represent those user journeys?","**Validate with users** — Does improving this SLI actually correlate with user satisfaction?","**Iterate and refine** — SLIs evolve as your understanding deepens"],"title":{"icon":"CheckCircle","text":"The SLI Selection Framework","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"Lightbulb","title":"Start Simple, Add Complexity Later","content":"A common mistake is defining too many SLIs initially. Start with 2-3 core SLIs:\n\n• **Availability**: Are requests succeeding?\n• **Latency**: Are they fast enough?\n• **Primary user journey**: Is the key use case working?\n\nAdd more specific SLIs only when you have evidence that these three don't capture important failure modes.","variant":"tip"},"type":"callout"},{"data":{"content":"### SLI Anti-Patterns to Avoid\n\n**Anti-Pattern 1: The Vanity SLI**\n\nMeasuring something that always looks good but doesn't reflect reality.\n\n*Example:* Measuring only 'server is up' (synthetic health check) while ignoring that 10% of real requests fail with timeouts.\n\n**Anti-Pattern 2: The Lagging SLI**\n\nMeasuring outcomes that users discovered hours ago.\n\n*Example:* Daily aggregated error counts. By the time you notice, thousands of users have already been impacted.\n\n**Anti-Pattern 3: The Too-Granular SLI**\n\nMeasuring at such fine granularity that normal variance triggers constant investigation.\n\n*Example:* Per-second error rate on low-traffic endpoints. A single failure creates 100% error rate for that second.\n\n**Anti-Pattern 4: The Hidden Context SLI**\n\nMeasuring without distinguishing fundamentally different request types.\n\n*Example:* Combined latency for 'quick lookup' and 'complex report generation' requests, making the SLI uninterpretable."},"type":"text"},{"data":{"left":[{"data":{"items":["Server CPU utilization","Database connection pool size","Queue depth (without context)","Number of active threads","Disk space remaining","Synthetic health check pass rate alone"],"title":{"icon":"XCircle","text":"Poor SLI Choices","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Request success rate (by endpoint class)","P99 latency for critical endpoints","End-to-end transaction success rate","Data freshness (for async systems)","Availability during peak hours","User-perceived error rate (client-side measurement)"],"title":{"icon":"CheckCircle","text":"Excellent SLI Choices","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"}],"titleType":"number","titleNumber":4},{"id":"sli-implementation","title":"SLI Implementation Patterns","content":[{"data":{"content":"Once you've selected your SLIs, implementation quality determines whether they're useful or misleading. Let's examine common implementation patterns and their tradeoffs."},"type":"text"},{"data":{"content":"### 1. Server-Side Metrics (Application Instrumentation)\n\n**How it works:** Your application code emits metrics for every request—latency, status code, endpoint, etc.\n\n**Pros:**\n- Rich contextual information (user ID, request type, etc.)\n- Easy to implement with metrics libraries\n- Can capture internal timing breakdowns\n\n**Cons:**\n- Doesn't capture network latency between server and user\n- Excludes failures that never reach your server (DNS failures, routing issues)\n- Requires code changes for each new metric\n\n**Best for:** Internal services, API backends, microservices"},"type":"text"},{"data":{"fileName":"sli-instrumentation-example","languages":[{"code":"$7a","label":"Python","value":"python"},{"code":"$7b","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"$7c"},"type":"text"},{"data":{"icon":"Info","title":"The Multi-Layered Approach","content":"Production systems typically implement SLIs at multiple layers:\n\n• **Client-side RUM** — Understanding true user experience\n• **Edge/Load Balancer** — Primary SLI data source for availability and latency\n• **Application metrics** — Detailed diagnostics and per-endpoint tracking\n• **Synthetic monitoring** — Continuous validation of critical paths\n\nEach layer has its purposes. The combination provides comprehensive visibility.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"sli-aggregation","title":"SLI Aggregation and Time Windows","content":[{"data":{"content":"Raw SLI measurements occur at the individual request level, but SLIs are typically reported as aggregated values over time windows. The choice of aggregation method and window size profoundly affects the utility of your SLI."},"type":"text"},{"data":{"content":"### Aggregation Methods\n\n**For Availability/Success Rate SLIs:**\n\n```\nSLI = (Sum of successful requests in window) / (Sum of total requests in window) × 100%\n```\n\nThis is straightforward—sum numerator and denominator separately, then divide.\n\n**For Latency SLIs:**\n\nTwo common approaches:\n\n1. **Percentile over window:** Calculate P99 of all requests in the window\n2. **Success rate below threshold:** What % of requests were faster than X ms?\n\nThe second approach (threshold-based) works better with SLO frameworks because it fits the 'good events / total events' model:\n\n```\nLatency SLI = (Requests < 200ms / Total requests) × 100%\n```"},"type":"text"},{"data":{"rows":[["1 minute","Fast detection of issues","Noisy, especially for low-traffic services","Alerting, real-time dashboards"],["5 minutes","Good balance of speed and stability","Still somewhat noisy","Operational dashboards"],["1 hour","Stable, less noise","Slow to detect issues","Reporting, trend analysis"],["28/30 days","Matches SLO evaluation periods","Very slow-moving","SLO burn rate, error budgets"]],"caption":"Time Window Selection","headers":["Window Size","Pros","Cons","Use Cases"]},"type":"table"},{"data":{"content":"### Rolling vs Fixed Windows\n\n**Rolling Windows:**\n- Look back from the current moment (e.g., 'last 30 days')\n- Continuously updated\n- Better for real-time SLO tracking\n- Example: 'Over the last 28 days, our availability was 99.95%'\n\n**Fixed Windows:**\n- Calendar-based (e.g., 'this month', 'this quarter')\n- Reset at boundaries\n- Better for contractual SLAs and reporting\n- Example: 'In Q3 2024, our availability was 99.93%'\n\n**Recommendation:** Use rolling windows for operational monitoring and SLO tracking. Use fixed windows for executive reporting and SLA compliance."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Aggregation Trap","content":"Be careful when aggregating SLIs across multiple services or endpoints. If Service A handles 1M requests at 99.9% success and Service B handles 1K requests at 90% success:\n\n• **Naive average:** (99.9 + 90) / 2 = 94.95% ← Misleading!\n• **Weighted average:** (999,000 + 900) / (1,000,000 + 1,000) = 99.89% ← Correct\n\nAlways weight by traffic volume, and consider whether aggregation is even meaningful for your use case.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"real-world-examples","title":"Real-World SLI Examples","content":[{"data":{"content":"Let's examine how different types of systems define their SLIs, drawing from real-world practices at scale."},"type":"text"},{"data":{"content":"### E-Commerce Platform SLIs\n\n**Critical User Journeys:**\n- Product browsing → Product detail view\n- Add to cart → Checkout → Payment\n- Order tracking\n\n**SLI Definitions:**\n\n1. **Search Availability:** % of search requests returning valid results (not errors)\n2. **Search Latency:** % of search requests completing in < 500ms\n3. **Checkout Availability:** % of checkout requests succeeding (payment processing works)\n4. **Checkout Latency:** % of checkout flows completing in < 3 seconds\n5. **Inventory Accuracy:** % of 'in stock' items actually available when ordered\n\n**Why these matter:** A user who can't search, add to cart, or checkout generates zero revenue. Each SLI directly ties to revenue impact."},"type":"text"},{"data":{"content":"$7d"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Industry-Specific Considerations","content":"Each industry has unique SLI requirements:\n\n• **Healthcare:** HIPAA compliance, audit logging success rate\n• **Gaming:** Matchmaking latency, session persistence\n• **IoT:** Device connectivity rate, command delivery success\n• **Advertising:** Bid request latency (strict <100ms), impression delivery rate\n\nUnderstand your industry's critical metrics before defining SLIs.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Mastering Service Level Indicators","content":[{"data":{"content":"We've covered the foundation of reliability measurement. Let's consolidate the key takeaways:"},"type":"text"},{"data":{"type":"ordered","items":["**SLIs are quantitative measures of user experience** — They transform reliability from subjective opinion into objective data.","**Good SLIs measure what users care about** — Success rate, latency, availability, not CPU or memory.","**The Four Golden SLIs cover most services** — Availability, Latency, Throughput, and Error Rate form a solid foundation.","**SLI selection is strategic** — Start simple with 2-3 core SLIs, expand only when you identify gaps.","**Implementation quality matters** — Where you measure (client, edge, server) affects what you capture.","**Aggregation requires care** — Time windows, weighting, and percentile calculation all affect SLI accuracy.","**SLIs are the foundation for everything else** — SLOs, SLAs, error budgets, and alerting all depend on well-defined SLIs."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nWith SLIs defining what we measure, we need to establish **targets** for acceptable performance. The next page explores **Service Level Objectives (SLOs)**—how to set meaningful reliability targets that balance user expectations with engineering reality."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand Service Level Indicators—the quantitative foundation of reliability engineering. SLIs transform 'is the service working?' from a subjective question into an objective, measurable, actionable metric. Next, we'll explore how to set targets for these indicators with Service Level Objectives.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_13eb5c1354b0e004584a13c8f9b151fb","title":"SLO: Service Level Objective","order":1,"content":null,"isLocked":true},{"id":"seed_cd52b294fb3daf611f9b9e6f706e62b5","title":"SLA: Service Level Agreement","order":2,"content":null,"isLocked":true},{"id":"seed_1a2c0243eaabff0bc06dd2f63fa3add3","title":"How SLIs, SLOs, and SLAs Relate","order":3,"content":null,"isLocked":true},{"id":"seed_bf4abea3ac0aee90139de6ab78fccbda","title":"Business Alignment","order":4,"content":null,"isLocked":true}]}}