SLIs tell us what to measure. SLOs tell us what targets to aim for. But when reliability commitments leave the engineering realm and enter contracts with customers, the stakes escalate dramatically. A Service Level Agreement (SLA) is a formal contract that specifies what level of service a customer can expect, and what compensation they receive if that level isn't met.

SLAs transform reliability from an internal engineering concern into a legal obligation with financial consequences. When you violate an SLA, you're not just disappointing users—you're potentially liable for service credits, refunds, or contractual damages.

A Service Level Agreement (SLA) is a formal, legally binding contract between a service provider and a customer that explicitly defines:

1. Service description — What service is being provided
2. Performance guarantees — What level of reliability/availability is promised
3. Measurement methodology — How compliance will be determined
4. Remedies — What happens if guarantees aren't met (typically service credits)
5. Exclusions — What circumstances don't count against the SLA

Unlike SLOs, which are internal targets that guide engineering decisions, SLAs are external promises with contractual weight. Violating an SLO affects your error budget and prioritization. Violating an SLA affects your revenue, reputation, and potentially legal standing.

Enterprise SLAs are complex legal documents, but the technical components follow a predictable structure. Let's dissect each element:

1. Service Description and Scope

What's covered:

An SLA must precisely define which services are included. Ambiguity leads to disputes.

Covered Services:
- Production API endpoints (api.example.com/*)
- Customer dashboard (dashboard.example.com)
- Webhook delivery system

Excluded Services:
- Sandbox/staging environments
- Beta features (marked with 'Beta' label)
- Third-party integrations
- Customer-managed infrastructure

Why precision matters:

If your SLA vaguely covers 'the platform,' a customer could claim SLA credits for issues in your internal admin tool or experimental features. Define boundaries explicitly.

2. Availability Definition

'Uptime' is not as simple as it sounds:

'Available' means the Service responds to valid API requests with
a non-5xx status code within 30 seconds. Requests that fail due to:
(a) Invalid authentication
(b) Rate limiting (429 responses)
(c) Client-side errors (4xx responses for malformed requests)
are not considered unavailable.

Common availability formulas:

Monthly Uptime % = (Total Minutes - Downtime Minutes) / Total Minutes × 100%

OR

Monthly Uptime % = (Successful Requests / Total Requests) × 100%

The request-based formula is more precise but requires robust measurement infrastructure.

3. Service Credit Structure

The financial consequence:

SLA violations typically trigger 'service credits'—discounts on future bills rather than cash refunds.

Common tiered structure:

Why credits, not refunds:

1. Keeps customers paying (credits apply to future bills)
2. Limits cash outflow during incidents
3. Incentivizes continued relationship
4. Often tax-advantaged compared to refunds

4. Exclusions and Limitations

What doesn't count against the SLA:

Exclusions:
1. Scheduled maintenance (with 72-hour advance notice)
2. Force majeure (natural disasters, war, etc.)
3. Customer-caused issues (code, configuration, attacks)
4. Third-party failures (AWS, payment processors)
5. Reasonable rate limiting to prevent abuse
6. Features marked as 'Alpha' or 'Beta'
7. Outages lasting less than 1 minute

The 'customer-caused' clause:

This is crucial. If a customer's code hammers your API causing them to get rate-limited, that's not an SLA violation. But proving the root cause requires good logging and forensics.

SLAs are ultimately financial instruments. Understanding their economics is essential for both setting appropriate commitments and managing the business implications of violations.

The Cost of Downtime

Direct SLA costs:

Monthly revenue: $1,000,000
SLA commitment: 99.9% (43.2 minutes allowed downtime)
Actual uptime: 99.5% (216 minutes downtime)

Credit tier triggered: 25% (95-99.9% tier)
Credit liability: $250,000

Indirect costs often exceed credits:

• Customer churn (lost future revenue)
• Sales cycle damage (prospects see your status page)
• Support costs (handling complaints)
• Engineering opportunity cost (incident response vs. features)
• Reputation damage (social media, press coverage)

Rule of thumb: For every $1 in SLA credits paid, downtime causes $5-10 in indirect costs.

The Risk-Reward Calculation

More aggressive SLAs win deals:

Enterprise customers often evaluate SLAs as part of vendor selection. Offering 99.99% when competitors offer 99.9% can win contracts.

But more aggressive SLAs increase exposure:

If you can't achieve 99.99%, you'll pay credits. If you consistently miss, you'll lose customers anyway.

The strategic calculation:

Expected SLA Credit Cost = P(violation) × E(credit amount per violation) × violations/year

If:
  P(missing 99.9%) = 15% per month
  Average credit if missed = $50,000
  Then: Expected annual cost = 0.15 × $50,000 × 12 = $90,000

Is $90,000/year acceptable to offer an SLA that wins $500,000/year in new business?

Setting SLA levels requires balancing competitive positioning with achievable reliability. Here's a systematic approach:

The 'SLA - SLO' Buffer

How much buffer is enough?

Scenario: SLO = 99.95%, SLA = 99.9%

Buffer = 99.95% - 99.9% = 0.05%
In 30 days, 0.05% = 21.6 minutes

This buffer absorbs:
- Minor incidents (< 22 minutes/month)
- Planned maintenance windows
- Measurement variance

Rule of thumb:

• Conservative: SLA = SLO - 0.1% (10x more lenient in downtime budget)
• Moderate: SLA = SLO - 0.05% (comfortable buffer)
• Aggressive: SLA = SLO - 0.01% (minimal buffer, higher risk)

Example:

Large enterprise customers often negotiate custom SLA terms beyond your standard published SLA. This can be profitable (larger deals) but also risky (larger exposure). Here's how to navigate these negotiations:

What Enterprises Typically Request

Higher availability targets:

'We need 99.99% availability, not 99.9%.'

Financial remedies beyond credits:

'If you're below 99.5%, we want the right to terminate without penalty.'
'SLA credits should be actual refunds, not credits against future bills.'

Custom measurement:

'We want to measure availability from our monitoring system, not yours.'
'Availability should be measured only during business hours (6 AM - 10 PM EST).'

Specific incident response times:

'Critical issues must have first response in 15 minutes.'
'Resolution SLA: Critical issues resolved in 4 hours.'

Penalties for repeated failures:

'If you miss SLA 3 months in a row, we can terminate.'
'Escalating credits: 15% first miss, 25% second, 50% third.'

Despite best efforts, SLA violations happen. How you handle them significantly impacts customer relationships and organizational learning.

Proactive vs Reactive Communication

Proactive approach (recommended):

Dear Customer,

We regret to inform you that on [date], our [Service] experienced an
outage lasting [duration]. This impacted your monthly uptime percentage,
which was [X%], below our SLA commitment of [Y%].

Per our Service Level Agreement, a credit of [amount] will be automatically
applied to your next invoice. No action is required on your part.

We take this seriously. A post-incident review is available at [link],
detailing root cause and preventive measures implemented.

Thank you for your patience and continued trust.

Why proactive is better:

1. Demonstrates accountability and transparency
2. Reduces support inquiries ('Am I getting a credit?')
3. Builds trust (you're not hiding bad news)
4. Controls the narrative (you frame the message)

The Credit Processing Workflow

Standard process:

1. Detection: Monitoring automatically flags SLA threshold breach
2. Validation: SRE confirms the breach, excludes any exclusions
3. Impact assessment: Finance calculates affected customers and credit amounts
4. Approval: Operations/Finance leadership approves credit batch
5. Application: Credits applied to billing system
6. Communication: Affected customers notified
7. Documentation: Incident + credits logged for reporting

Learning from SLA Violations

Beyond just paying credits:

An SLA violation should trigger deeper analysis:

1. Why did we miss the SLO? (The SLO should catch problems before SLA breach)
2. Was our SLA too aggressive? (Strategic mismatch with capability)
3. What systematic improvements are needed? (Not just incident fixes)
4. Should we adjust monitoring/alerting? (Earlier detection next time)
5. Are there customer-specific factors? (Geographic, usage patterns)

The SLA violation retrospective:

Schedule a quarterly review of all SLA violations:

• Which customers were affected?
• What was the total credit impact?
• Are violations concentrated in specific services?
• Is there a trend (improving or worsening)?
• What reliability investments are justified by credit reduction?

Let's examine how major cloud providers and SaaS companies structure their SLAs. These examples represent industry best practices and common patterns.

AWS EC2 SLA (Simplified)

Commitment: 99.99% Monthly Uptime Percentage

Credit structure:

• 99.0% - 99.99%: 10% credit
• 95.0% - 99.0%: 30% credit
• < 95.0%: 100% credit (month is free)

Key exclusions:

• Scheduled maintenance
• Customer-caused issues
• Force majeure
• Individual instance failures (only region-wide counts)

Claim process: Customer must submit within 30 days of billing cycle end.

Google Cloud Platform SLA (Simplified)

Commitment: Varies by service (99.95% - 99.999%)

Interesting feature: Google offers tiered SLAs based on architecture:

• Single zone deployment: 99.5%
• Multi-zone deployment: 99.99%

This incentivizes customers to build resilient architectures.

Stripe API SLA

Commitment: 99.99% uptime for core payment processing

Unique aspects:

• Very specific about what endpoints are covered
• Separate SLAs for different API categories
• Enterprise plans include custom response time SLAs
• Public status page tracking as part of SLA transparency

Patterns Across Industry SLAs

Common elements:

1. Conservative targets: Most SLAs are 99.9% (three nines), even from companies achieving higher
2. Credits, not refunds: Almost universally use service credits
3. Capped liability: Credits rarely exceed 100% of monthly fee
4. Customer claim requirement: Customers must actively request credits
5. Exclusions list: All SLAs have extensive exclusions
6. Time-bounded claims: 30-60 day claim windows

Lessons for your SLA:

• Industry practice provides a defensible baseline
• Customers familiar with cloud SLAs have calibrated expectations
• Unusual SLA terms (very high commitments, cash refunds) are red flags to experienced buyers

SLAs transform reliability from an engineering concern into a contractual commitment with financial consequences. Setting and managing SLAs requires collaboration between engineering, legal, finance, and sales.

What's next:

With SLIs, SLOs, and SLAs now established, we need to understand how they interrelate in practice—the feedback loops, escalation paths, and organizational dynamics that make reliability management work.