Service Level Agreement (SLA)

The specific, measurable performance target that defines acceptable behavior. This is the numerical threshold the system must meet.

• Example: P99 latency must be ≤ 200ms.
• Measurement Window: Typically calculated over a rolling 28-day period.
• Distinction: An SLO is an internal engineering goal, while the SLA is the external business promise derived from it.

The explicit amount of acceptable unreliability derived from the SLO. It represents the maximum time a service can fail before breaching the contract.

• Formula: 100% minus the SLO target. For a 99.9% SLO, the error budget is 0.1% (43 minutes of downtime per month).
• Function: This budget is the release valve for engineering velocity. Teams can deploy risky features as long as they have budget remaining.

The precise definition of how performance is calculated. Ambiguity here renders the SLA unenforceable.

• Latency Metrics: Must specify percentile (P50, P95, P99) and measurement point (server-side vs. client-side).
• Availability: Defines uptime percentage, often excluding planned maintenance windows.
• Synthetic Monitoring: Uses simulated user traffic to verify performance independently of real user fluctuations.

The financial or contractual consequences triggered when the SLO is breached. This is the enforcement mechanism that aligns vendor incentives with customer reliability.

• Service Credits: A percentage of the monthly bill refunded to the customer, often tiered (e.g., 10% credit for <99.9% uptime, 25% for <99%).
• Termination Rights: The customer's right to cancel the contract without penalty after repeated or severe failures.

The specific scenarios where the SLA guarantees do not apply. These carve-outs protect the provider from liability for failures outside their direct control.

• Force Majeure: Natural disasters, wars, or large-scale internet backbone failures.
• Customer-Controlled Factors: Failures caused by customer code, configuration errors, or exceeding provisioned capacity limits.
• Planned Maintenance: Pre-scheduled downtime communicated in advance, typically excluded from availability calculations.

The mechanism for transparently verifying compliance. Trust in an SLA is built on verifiable data, not blind faith.

• Public Status Pages: Real-time dashboards showing current and historical uptime (e.g., trust.example.com).
• Audit Logs: Immutable records allowing customers to independently verify reported metrics against their own client-side telemetry.
• Third-Party Validation: External auditors certifying that measurement systems are accurate and unbiased.

The specific, measurable internal target that engineering teams use to satisfy the broader SLA. While an SLA promises 99.9% uptime to the customer, the internal SLO might be set at 99.95% to create a safety buffer.

• Key distinction: SLAs are customer-facing contracts with financial penalties; SLOs are internal engineering goals.
• Example: If your SLA guarantees a P99 latency of < 200ms, your SLO should target < 150ms to absorb infrastructure variance.
• Relationship: Failing an SLO triggers internal alerts; failing an SLA triggers customer credits or contract termination.

The response time threshold that 99% of requests fall below, representing the near-worst-case experience users encounter. This is the most common metric codified in latency-sensitive SLAs because it captures tail latency without being skewed by extreme outliers.

• Why P99? Averages hide suffering. A system with 50ms average latency can still have 1% of users waiting 5 seconds.
• SLA context: An SLA might state 'P99 latency shall not exceed 200ms per calendar month.'
• Calculation: Collect all request latencies, sort them, and find the value at the 99th percentile.

The high-latency edge cases in a distribution of service response times, typically measured at the 90th, 99th, or 99.9th percentile. These outliers are the primary threat to meeting SLA commitments in distributed systems.

• Causes: Garbage collection pauses, network congestion, disk I/O contention, and queueing delays.
• Mitigation: Hedged requests (sending the same request to multiple replicas and using the first response) and circuit breakers to shed load from slow backends.
• SLA impact: A single slow backend service can cascade tail latency through the entire retrieval pipeline, breaching the end-to-end SLA.

The explicit amount of downtime or failed requests an SLO permits before the SLA is breached. It represents the 'acceptable unreliability' that teams can spend on innovation, maintenance, or calculated risk.

• Formula: Error Budget = 1 - SLO Target. For a 99.9% SLO, the monthly error budget is approximately 43 minutes of downtime.
• Operational use: Once the error budget is exhausted, all feature launches freeze until reliability is restored.
• SLA linkage: The error budget is the engineering team's buffer; exceeding it means the SLA is now at immediate risk of violation.

A stability pattern that automatically stops requests to a failing downstream service, immediately returning an error or fallback response. This prevents a slow or dead dependency from consuming resources and causing a cascading failure that would breach the SLA.

• States: Closed (normal operation), Open (requests blocked), Half-Open (limited trial requests to test recovery).
• SLA protection: By failing fast instead of waiting for timeouts, circuit breakers preserve the P99 latency of the overall system.
• Implementation: Libraries like Netflix Hystrix or Polly monitor failure rates and automatically trip the breaker.

A design strategy where a system maintains partial core functionality by disabling non-critical features when a dependency fails, rather than suffering a complete outage. This is a critical pattern for preserving SLA uptime guarantees.

• Example: A search engine might disable personalized recommendations (which depend on a slow user-profile service) but continue serving core keyword search results.
• SLA context: An SLA might permit degraded mode operation as 'available' if core functionality remains intact.
• Implementation: Requires explicit fallback paths and feature flags to surgically disable components.