Service Level Agreements (SLAs): Uptime Commitments, Response-Time Promises, Credits, and the Math That Holds Up

⬅️ Day 6: Grow Overview

If you're running a SaaS in 2026 and haven't formalized SLAs, the first enterprise prospect will ask for them and you'll write something on the spot — usually too aggressive, often unmeasurable, sometimes unbounded in liability. Three months later you're paying credits you didn't budget for, or arguing with a customer about whether last Tuesday's degradation "counted." The contract you signed in fifteen minutes is now driving operational decisions for the next twelve.

A working SLA does specific work: it defines the uptime commitment (99.9%? 99.95%?), the response-time targets for support, the exclusions that prevent unbounded liability, and the credit formula that's automatic, capped, and verifiable. Done well, SLAs win enterprise deals while keeping your engineering team out of contract-arbitration hell. Done badly, you've promised four 9s on a single-region database with no on-call rotation and you're paying credits you can't afford.

This guide is the implementation playbook for SLAs that close enterprise deals without bankrupting you — the math, the legal language, the operational hooks, and the renewal-time review cadence.

Decide Whether You Even Need a Formal SLA

SLAs are not free. Once you sign one, you must measure it, report on it, and pay credits when you miss it. Don't sign one for a $99/mo customer.

Help me decide if I need a formal SLA today.

The signals to add a formal SLA:

**Add a formal SLA when**:

- Annual contract value > $5K/yr (the credit dollars are not catastrophic)
- Enterprise prospects asking for it (procurement-driven)
- You have basic observability + on-call (you can actually measure / respond)
- Multiple customers depend on you for production workflows
- Sales process is sales-led (per [self-serve-vs-sales-led](https://www.launchweek.com/4-convert/self-serve-vs-sales-led))
- You can run a single-customer "trial SLA" first (negotiate concrete terms with one customer)

**Don''t add a formal SLA when**:

- Self-serve under $1K/yr ACV (overhead > deal value)
- No 24/7 on-call (you can''t honor response-time commitments)
- Single-region single-AZ (uptime guarantees are mathematical fiction)
- Brand-new product with <10 paying customers
- Founder is still the only on-call (sleep matters)

**The "marketing SLA" alternative**:

Before formal SLAs, many indie SaaS publish "target uptime" without contractual commitment:

> "We target 99.9% uptime. See our public status page for historical data."

This signals competence to evaluators without legal liability. Use it as a stepping stone.

**The "Pro plan SLA" pattern**:

Some SaaS reserve formal SLAs for higher tiers:

- Free / Starter: no SLA; status page only
- Pro: 99.5% uptime target; no credits
- Business: 99.9% uptime + credit policy
- Enterprise: 99.95% + custom terms

This lets you charge for the SLA capability and keeps credit exposure aligned with revenue.

For my company today:
- Current ACV / customer mix
- Current observability + on-call
- Sales motion
- Customers asking for SLAs

Output:
1. The decision: add formal SLA / publish target / wait
2. The tier where SLA kicks in (if tiered)
3. The minimum infrastructure required to honor it
4. The 6-month roadmap to readiness if not yet ready

The biggest unforced error: agreeing to "99.99% uptime" on a single-region, single-AZ database with one on-call engineer. Four-9s mathematically requires multi-AZ minimum, often multi-region, and a 24/7 rotation. Promising it without the infrastructure is a credit liability waiting to trigger. Match SLA promises to the actual reliability you can deliver — not the number that sounded good in the sales meeting.

The Three Numbers That Matter

Every SLA has three core commitments. Get them right; everything else follows.

Help me set the three SLA numbers.

**1. Uptime / availability**

The percentage of time the service is operational.

| Target | Annual downtime allowed | Monthly downtime allowed | What it really requires |
|---|---|---|---|
| 99.0% (two 9s) | 87.6 hours | 7.3 hours | Single-region, manual on-call OK |
| 99.5% | 43.8 hours | 3.65 hours | Single-region, alerting + runbooks |
| 99.9% (three 9s) | 8.76 hours | 43.8 minutes | Multi-AZ, on-call rotation, runbooks |
| 99.95% | 4.38 hours | 21.9 minutes | Multi-AZ, 24/7 on-call, automated failover |
| 99.99% (four 9s) | 52.6 minutes | 4.38 minutes | Multi-region active-active, mature SRE |
| 99.999% (five 9s) | 5.26 minutes | 26.3 seconds | Telco-grade; not appropriate for indie SaaS |

**Default for indie SaaS in 2026**: 99.9%. Hits the "respectable" bar without requiring multi-region.

**2. Support response time**

The time within which support acknowledges (not resolves) a ticket.

| Severity | Definition | Response SLA (typical) |
|---|---|---|
| Sev 1 / Critical | Production down; no workaround | 1 hour 24/7 |
| Sev 2 / High | Major feature broken; workaround exists | 4 business hours |
| Sev 3 / Normal | Minor issue; not blocking | 1 business day |
| Sev 4 / Low | Question / feature request | 3 business days |

**Acknowledge ≠ resolve**. Always commit to acknowledgment, never resolution time (resolution depends on complexity).

**3. Credit policy**

What customers get when you miss the SLA.

Standard structure:

| Uptime achieved | Service credit (% of monthly fee) |
|---|---|
| 99.9% - 100% | 0% (target met) |
| 99.0% - 99.9% | 10% credit |
| 95.0% - 99.0% | 25% credit |
| <95.0% | 50% credit (capped) |

**Critical caps and conditions**:

- Credits capped at one month''s subscription fee (no compounding)
- Credits applied to next month''s invoice (not cash refund)
- Customer must request credit within X days of incident (typically 30)
- No credits for excluded events (see "Exclusions" below)
- No credits if customer is in payment delinquency

**Why credits matter**:

- Skin in the game: customer trusts you because you''ll lose money on outages
- Bounded liability: you know maximum exposure (~50% of monthly fees in worst month)
- Forcing function: credits paid → engineering investment in reliability

**The "credits are alignment, not punishment" principle**:

The point of SLA credits isn''t to make customer whole on outage cost (impossible). It''s to align your incentives with their reliability. A customer paying $10K/mo and losing $500K/day on an outage doesn''t get made whole by a $5K credit — they get made whole by you fixing the underlying reliability problem.

For my company:
- Uptime target appropriate to infrastructure
- Response-time SLA aligned with on-call rotation
- Credit table aligned with monthly fees

Output:
1. The three numbers (uptime / response / credit)
2. The infrastructure required to honor them
3. The credit-budget worst-case calculation
4. The renewal cadence to revisit numbers

The biggest single-number mistake: promising response time you can''t honor on weekends. "1-hour Sev 1 response" requires 24/7 on-call. If the founder is the only on-call and goes camping, you breach. Either build 24/7 capacity (rotation; outsourced on-call; Pingdom + escalation) or scope the SLA to business hours only ("1-hour Sev 1 response during business hours; 4-hour off-hours").

Exclusions That Prevent Unbounded Liability

The fine print is where bad SLAs get good or great SLAs get destroyed. List exclusions explicitly.

Help me write SLA exclusions.

The standard exclusion list:

**1. Scheduled maintenance**

> "Scheduled maintenance windows announced at least 7 days in advance, not exceeding 4 hours per month, do not count toward downtime."

Best practice: schedule for low-traffic windows (Saturdays 2-4am UTC); announce on status page; email customers.

**2. Customer-caused outages**

> "Outages caused by customer misconfiguration, customer-side network issues, or actions taken by the customer''s authorized users are not subject to credits."

Examples: customer hits rate limit due to their own runaway loop; customer''s admin disables critical features.

**3. Third-party / upstream provider failures**

> "Outages caused by failures of third-party services upon which [Company] depends (DNS providers, payment processors, AI providers, etc.) are not subject to credits."

Some customers push back on this; weaken to "credits at 50% of normal" if needed.

**4. Force majeure**

> "Outages caused by events beyond reasonable control (natural disasters, war, government action, internet-wide outages) are not subject to credits."

Standard legal language; non-negotiable for most.

**5. Beta features**

> "Features marked as beta, preview, or experimental are not covered by this SLA."

Critical for shipping new features fast without taking on SLA risk.

**6. Customer payment delinquency**

> "Credits are not available to customers in payment delinquency or with overdue invoices."

Reasonable; prevents abuse.

**7. Free trial / proof-of-concept periods**

> "Trial / POC periods are not covered by this SLA."

Standard.

**8. Intentional outages from customer-side**

> "Outages from customer-initiated penetration testing, load testing, or DoS testing without prior agreement are excluded."

Helpful when customers run tests that take you down.

**9. Data center / cloud-provider failures**

> "Outages caused by failures of underlying cloud infrastructure (AWS / GCP / Azure regions) are subject to credits at the same level passed through from the cloud provider''s SLA."

Reasonable: if AWS is down, you''re down; AWS will credit you; you pass through.

**10. Compliance with reasonable security guidance**

> "Customer must follow [Company]''s published security best practices; non-compliance leading to outages excludes credits."

Edge case; useful for credential-leak scenarios.

**The "exclusions list trap"**:

If exclusions consume more pages than the SLA itself, customers will rightly suspect the SLA is theatre. Keep exclusions to a tight list (5-8 items) that covers obvious edge cases without becoming a swiss-cheese promise.

For my SLA:
- The 5-8 exclusions appropriate for my product
- The customer-perception check (does this still feel like a real SLA?)

Output:
1. The exclusions list
2. The legal review checklist
3. The "customer perception" test (read aloud; does it still feel solid?)

The biggest exclusions mistake: excluding so much that the SLA is meaningless. A 99.99% SLA with exclusions for "scheduled maintenance, third parties, force majeure, beta features, customer-caused, AWS-caused, network-caused, and any single component failure" guarantees nothing measurable. Customers (and their lawyers) will see through this. A real SLA includes some exposure to your reliability decisions; that''s the whole point.

How You Actually Measure Uptime

Promising 99.9% is meaningless if you can''t measure it. Pick the methodology before signing.

Help me design uptime measurement.

The question: what does "down" actually mean?

**Three measurement models**:

**Model A: Synthetic / external monitor**

- External service (UptimeRobot, Better Uptime, Pingdom) hits your API every minute
- Failed check counts as down
- Counts measured per-minute; aggregated to monthly uptime %

Pros: simple; objective; what customers actually experience
Cons: external monitor outage shows as your outage; one endpoint isn''t the full product

**Model B: Customer impact-based**

- Internal observability detects when X% of requests fail or latency exceeds threshold
- "Down" = >5% of requests failing for >5 minutes (per [error-monitoring-providers](https://www.vibereference.com/devops-and-tools/error-monitoring-providers))
- Aggregated by component (API / dashboard / webhooks / etc.)

Pros: reflects customer experience; component-level granularity
Cons: more complex to define; argument over thresholds

**Model C: Hybrid**

- Synthetic for headline uptime number
- Customer-impact for component-level reporting on status page
- Whichever is worse counts for SLA breach

Most mature.

**Component model**:

A single uptime number is misleading. A working SLA defines components:

| Component | What it covers | Threshold |
|---|---|---|
| API | All `/api/*` endpoints | <2% error rate; p95 < 500ms |
| Dashboard | Web UI | Page loads in <3s; <2% errors |
| Webhooks | Outbound webhook delivery | <5% deliveries delayed >5min |
| Email | Email sends | >99% delivered within 1 minute |

Each component has its own uptime number; SLA is breached if ANY component falls below target for the month.

**Granularity**:

- 1-minute checks: standard for API
- 5-minute checks: acceptable for less-critical components
- Daily aggregation: "this day was X% up"
- Monthly aggregation: total minutes up / total minutes in month

**Reporting**:

- Status page shows historical uptime (e.g., "99.94% over last 90 days")
- Monthly customer-facing report (email or PDF for enterprise)
- Per-incident detail with start/end timestamps

**Tools**:

| Tool | Cost | Purpose |
|---|---|---|
| UptimeRobot | Free / $7/mo | Synthetic checks |
| Better Uptime | $24/mo | Status page + monitoring |
| Pingdom | $15/mo | Synthetic checks |
| Datadog Synthetics | $5+/test/mo | Enterprise synthetic |
| Internal observability | varies | Customer-impact model |
| StatusPage.io | $79/mo | Customer-facing status page |

**The reproducibility test**:

Can a customer who suspects you breached SLA verify the math themselves?

- Status page shows historical data they can check
- Specific incidents are timestamped
- Component model is published

If they have to take your word for it, the SLA isn''t real.

For my system:
- Measurement model (A / B / C)
- Component definitions
- Tooling decisions
- Public-reporting cadence

Output:
1. The measurement methodology
2. The components defined
3. The tools / costs
4. The public reporting plan

The biggest measurement mistake: using internal-only data with no public verification. A customer disputes a downtime claim; you point to "internal logs"; they shrug because they can''t see them. A public status page (per status-page-chat) plus an external synthetic monitor produces verifiable history that takes arguments off the table. Trust = transparency.

Build the Operational Hooks

An SLA without operational hooks is decoration. Wire it into how you actually run.

Help me wire SLAs into operations.

The hooks:

**1. Real-time alerting**

When SLA-relevant components degrade:
- Sev 1: page on-call immediately
- Sev 2: page on-call within 15 minutes
- Slack / Pagerduty integration

**2. SLA-budget tracking**

Monthly:
- Count downtime minutes per component
- Compare against allowed budget (e.g., 43.8 min/month for 99.9%)
- "We''ve used 23 of 43.8 minutes this month — flag if approaching limit"

This is the **error budget** concept (per Google SRE) — when you''ve burned the budget, slow down feature shipping; invest in reliability.

**3. Customer-impact triage**

When an incident happens:
- Tag affected customers in CRM
- Calculate which customers are SLA-eligible
- Pre-compute potential credits
- Outreach proactively (don''t wait for them to ask)

**4. Credit issuance flow**

When SLA is breached:
- Auto-calculate credits for affected customers
- Apply to next invoice (not cash refund)
- Email notification + apology
- Internal post-mortem (per [incident-response-chat](incident-response-chat.md))

**5. Renewal-time SLA review**

At each customer renewal:
- Pull last 12 months uptime per component
- Honest assessment: did we hit the targets?
- Adjust target if reality has shifted (raise or lower)

**6. Quarterly internal review**

- Are we hitting SLA across the customer base?
- What''s the credit exposure trend?
- Are exclusions being abused (customer-caused but we''re still paying)?
- Renewal language updates needed?

**7. The "SLA is a forcing function" rule**

When you breach SLA repeatedly:
- That''s a signal to invest in reliability (not negotiate the SLA down)
- Credit cost is the bill for shipping faster than your reliability allows
- Sometimes the right answer is: stop shipping features for 2 weeks; harden infra

**Anti-patterns**:

- SLAs in legal docs that ops never sees
- No alerting tied to SLA breach
- Credits calculated manually each month (auto-calculate)
- Customers asking and getting different answers from sales / support / engineering

**The error-budget conversation**:

> "We have 4.38 minutes of allowed downtime this month. We just had a 6-minute incident. We''re over budget. Anything that''s not reliability work is paused for 2 weeks."

This is the most powerful organizational use of an SLA — translating customer commitments into engineering priorities.

For my operations:
- Alerting wired to SLA components
- Budget tracking
- Credit-issuance automation
- Renewal SLA review process

Output:
1. The alerting wire-up
2. The error-budget dashboard
3. The credit-flow runbook
4. The renewal-time SLA review template

The biggest operational mistake: letting SLA exist only in the contract. If engineering doesn''t see daily error-budget, sales doesn''t know what the SLA promises, and support doesn''t triage by SLA priority — the SLA is a piece of paper, not an operational discipline. Wire it through every team that touches reliability or customer escalation.

Common SLA Negotiation Asks (and How to Answer Them)

Enterprise customers will push on standard SLAs. Anticipate the asks; have ready answers.

Help me handle SLA negotiation asks from enterprise prospects.

Common asks + responses:

**Ask 1: "We need 99.99% uptime."**

You: "Our current infrastructure supports 99.9%. We can target 99.99% with [specific upgrades: multi-region failover, dedicated compute, 24/7 SRE on-call]. Pricing for that tier is [+30% / +$X custom]."

If they push without paying for upgrades: hold the line. 99.99% on infrastructure that supports 99.9% is fraud.

**Ask 2: "Credits should be cash refunds, not service credits."**

You: "Industry-standard is service credit applied to next invoice. We can negotiate up to [X% of breach value] in cash if [conditions]. Higher-tier alternative: pre-negotiated cash limit at [enterprise tier]."

Service credits are standard for a reason — they''re predictable; cash refunds destabilize cash flow.

**Ask 3: "Liability cap of 12 months fees."**

You: "Standard liability cap for SLA breach is one month''s fees. We can extend to 3 months for enterprise tier. Beyond that requires legal review and pricing adjustment."

Don''t let liability go uncapped or to 12 months without compensating revenue.

**Ask 4: "Define ''downtime'' more strictly — any error counts."**

You: "Industry standard is sustained customer-facing impact (>X% errors for >Y minutes). Defining ''any error'' creates measurement noise from transient blips that customers don''t experience. We can negotiate the threshold."

Hold the line on threshold-based; help them understand why.

**Ask 5: "Remove the third-party exclusion."**

You: "We can split this — third-party failures (DNS, payment processors, AI providers) excluded; cloud-provider failures (AWS / GCP) credited at pass-through rate."

Reasonable middle ground.

**Ask 6: "SLA must apply to all features including beta."**

You: "Beta features are explicitly experimental and not yet ready for SLA-bound use. We can offer ''general availability'' versions on roadmap commitment timeline."

Hold the line; beta exclusion is essential.

**Ask 7: "Custom SLA report monthly with breakdown."**

You: "We can provide custom monthly reports for enterprise tier ($X/mo addon)."

Charge for it; it''s real ops work.

**Ask 8: "SLA must be enforceable — what happens if you stop paying credits?"**

You: "Standard enforcement is invoicing dispute / arbitration. We can add a termination-for-cause clause if SLA is breached >X consecutive months."

Reasonable.

**The pricing-up ladder**:

Standard SLAs at standard prices. Custom SLAs at custom prices. Don''t give away free uptime upgrades; price them.

| Tier | Uptime | Response Sev 1 | Credit cap | Pricing |
|---|---|---|---|---|
| Pro | 99.5% | 4 business hours | 10% | Standard |
| Business | 99.9% | 1 hour business / 4 off | 25% | +20% |
| Enterprise | 99.95% | 1 hour 24/7 | 50% | Custom |
| Premium | 99.99% | 30 min 24/7 + dedicated CSM | 100% | Custom + 50%+ |

For my upcoming negotiations:
- Common asks I expect
- The pre-built responses
- The walk-away points

Output:
1. The negotiation playbook
2. The tiered SLA pricing
3. The "what we won''t agree to" list
4. The escalation path for customer demands beyond playbook

The biggest negotiation mistake: agreeing to enterprise-tier SLA on standard-tier pricing. A customer paying $10K/yr who demands 99.99% uptime and 12-month liability is asking you to operate at $200K/yr cost on $10K revenue. Either price up or walk away. The relationships you can''t price up are usually the wrong ones to take.

Renew, Review, Don''t Drift

SLAs aren''t set-and-forget. Build the review cadence.

Help me set up SLA review cadence.

The cadence:

**Monthly**:

- Compute uptime per component
- Compare to SLA targets
- Issue credits to affected customers (auto)
- Update status page with monthly summary
- Internal review: any near-breaches?

**Quarterly**:

- Aggregate SLA performance across all customers
- Credit cost: total dollars given as SLA credits
- Identify infrastructure investments needed
- Update sales materials if reality has shifted

**Annually (with each customer renewal)**:

- Show customer their last 12 months actual uptime
- Discuss whether SLA target is still appropriate
- Sometimes raise targets (build trust); sometimes lower (be honest)
- Update SLA addendum if changes

**On significant events**:

- New cloud-provider relationship → update third-party exclusions
- New on-call structure → update response-time commitments
- Major incident → review whether SLA was reasonable
- Architectural shift (multi-region rollout) → can offer better SLA

**The "honesty calibration" principle**:

When in doubt, target an SLA you''re currently 1.5x exceeding:

- Currently doing 99.95% actual? Target 99.9% in SLA.
- Currently doing 99.5% actual? Target 99.0% in SLA.

This builds in margin for variance and avoids constant credits. Better to over-deliver than under-promise.

**The "credit-cost is information" rule**:

If you''re paying $5K/quarter in SLA credits, that''s telling you:
- Reliability investment cost: <$5K/quarter is rationalized
- Customer pain is real; relationship damage too
- Either fix the reliability or lower the target — drifting isn''t free

**Anti-patterns**:

- Same SLA for 3 years with no review (drift)
- Lowering SLA quietly without telling customers
- Raising SLA mid-contract without compensation
- Credits paid out without root-cause investigation
- SLA review by legal only (engineering must be in the room)

For my company:
- The review cadence (calendar)
- The owners (eng / sales / legal each have a role)
- The customer-facing communication when SLA changes

Output:
1. The annual SLA review calendar
2. The owner assignments
3. The communication templates
4. The "we''re raising / lowering targets" customer-letter template

The biggest review-cadence mistake: never reviewing because nobody owns it. SLAs sit in legal docs that engineering never reads, sales doesn''t track, and customers can''t verify. A 30-minute quarterly review with eng + sales + finance keeps the SLA aligned with reality. Without it, drift compounds; one day a customer calls in a breach that engineering didn''t even know was happening.

Avoid Common Pitfalls

Recognizable failure patterns.

The SLA mistake checklist.

**Mistake 1: Promising more than infrastructure delivers**
- 99.99% on single-region without SRE
- Fix: match SLA to actual reliability; upgrade infra OR lower SLA

**Mistake 2: Unbounded liability**
- No credit cap; customer claims $1M for $10K/mo product
- Fix: cap at 1-3 months fees

**Mistake 3: No measurement methodology**
- "99.9% uptime" with no defined "down"
- Fix: published methodology + public verification

**Mistake 4: Manual credit calculation**
- Credits calculated ad-hoc; sometimes given; sometimes not
- Fix: automate from monitoring data

**Mistake 5: SLA in legal doc that ops never reads**
- Engineering doesn''t know what''s promised
- Fix: SLA dashboard visible to eng; ties to error budget

**Mistake 6: Same SLA across all tiers**
- Free customer demands enterprise-grade SLA
- Fix: tier the SLA

**Mistake 7: No exclusions**
- Customer-caused outage → you pay
- Fix: standard exclusions list

**Mistake 8: Only focus on uptime**
- SLA misses response-time commitments; customer''s real pain
- Fix: include support response SLA

**Mistake 9: SLA as marketing copy without contract teeth**
- "We target 99.9%" published but never honored
- Fix: either deliver real credits or call it ''target'' (transparently)

**Mistake 10: Negotiate down customer-by-customer**
- Different SLAs per customer; chaos at renewal
- Fix: standard tiered SLAs; only enterprise gets custom

**The quality checklist for any SLA**:

- [ ] Uptime target matches infrastructure capability
- [ ] Response-time SLA matches on-call coverage
- [ ] Credit policy with auto-calculation
- [ ] Credit cap (1-3 months fees)
- [ ] Exclusions list (5-8 items)
- [ ] Measurement methodology published
- [ ] Public status page with verifiable history
- [ ] Reviewed at renewal
- [ ] Wired to error-budget operationally
- [ ] Sales / eng / legal aligned on terms

For my SLA:
- Audit against this checklist
- Top 3 fixes

Output:
1. The audit
2. Top 3 fixes prioritized
3. The "ship the v2 SLA" plan

The single most-common mistake: agreeing to SLA terms in a sales meeting without engineering review. A founder closes the deal, signs the SLA, then engineering finds out about it three months later when the first incident triggers credits. Always: SLA terms must pass through engineering before signing. The 30 minutes of friction prevents 12 months of pain.

What "Done" Looks Like

A working SLA system in 2026 has:

Tiered SLAs aligned with pricing tiers (Pro / Business / Enterprise)
Uptime targets matched to actual infrastructure capability
Public measurement methodology + verifiable status page
Standard exclusions list (5-8 items)
Capped credit policy (1-3 months fees max)
Auto-calculated credit issuance
Operational hooks: error-budget dashboard; customer-impact triage; renewal review
Sales / engineering / legal alignment on standard terms
Quarterly review of credit cost as reliability-investment signal
Custom enterprise SLAs only at enterprise pricing

The hidden cost of weak SLAs: paying credits forever without fixing the underlying reliability. A founder treats SLA credits as a customer-relations expense rather than a reliability signal. Six months in, they''re burning $10K/quarter on credits while shipping features at the same pace. The SLA was supposed to be a forcing function; instead it''s an annuity. Wire SLAs into engineering decision-making, or they''re just expensive marketing.