SLA vs Support & Services

There are two layers to what a vendor promises you. The first is the contractual SLA: a number with a remedy. The second is everything else they sell to help you: premium support, designated humans, architecture reviews, professional services. Both are valuable. Only one is a guarantee. People mix them up all the time. Here is the line.

The SLA contractual

What the provider legally owes you when their uptime slips.

  • Uptime commitment (e.g. 99.9% / month)
  • Service credits with a defined % and cap
  • Claim window (usually 30–60 days)
  • A measurement method and a remedy if you file in time
Wording that signals a real SLA: "guarantees / shall", a Service Credit schedule, a claim process, a cap, an exclusive remedy.

Support & Services target / entitlement

What you can buy to get more help. Useful, often paid, almost never credit-backed.

  • Support response times (Sev1 in 15 minutes, etc.)
  • 24x7 coverage and faster escalation
  • Designated humans: TAM, CSM, named architect, support team
  • Architecture / Well-Architected reviews
  • Professional services (sold via SOW)
  • Customer success programs, training, enablement
Wording that signals an entitlement, not an SLA: "target", "objective", "SLO", "estimated", "commercially reasonable efforts", "every reasonable effort". No credit table, no claim window, no remedy.

Why this matters

If a provider's salesperson tells you "we have a 15-minute response SLA," that number is almost always a target sitting inside a support plan, not a credit-backed promise. A missed 15-minute response usually has no remedy beyond "we'll try harder," or at most "we'll re-perform the support." The genuinely enforceable promise — the one tied to money — is the uptime SLA above the support tier.

The reverse is also true. The premium support and services layer might be worth far more than the uptime credits ever will be — a Technical Account Manager who knows your architecture, a quarterly Well-Architected review, a 24x7 designated team for Sev1. Especially when the outage is on your side, not the provider's.

How to read a vendor doc in 30 seconds

You see this wordingTreat it as
guarantees, shall, with a Service Credit schedule + cap + claim windowSLA (credit-backed)
target, objective, SLO, estimated, commercially reasonable efforts, every reasonable effortTarget / SLO (no remedy)
included with X tier, designated TAM, access to architecture reviewEntitlement (you can call on it, no measured outcome)
A Statement of Work (SOW) with deliverables, milestones, acceptance criteriaContractual deliverable (the one place "soft" services become measurable)

What each role actually cares about

FinOps & procurement

"What am I legally owed, and what does the insurance cost?"

  • Uptime %, credit %, cap, exclusions
  • Claim mechanics, window, automatic vs filed
  • Premium-support cost as a % of spend, and what it buys
  • Chronic-failure / termination rights — the real leverage
DevOps & SRE

"Can this provider help us run it better, and respond fast when it breaks?"

  • Sev1 response targets (treat as SLOs, not guarantees)
  • Designated TAM/CSM/team — continuity and expertise
  • Architecture / Well-Architected reviews
  • 24x7 escalation, professional services for migrations
Support & IT leaders

"Coverage, escalation, and accountable contacts."

  • Response times per severity, business vs 24x7
  • Designated / named contacts and escalation paths
  • Authorized contacts, case-volume limits per tier
  • Training, onboarding, enablement entitlements

How SLA.directory shows this

On every vendor page we keep the two layers clearly separated. The SLA report card at the top is the contractual layer: uptime, credits, claim window, premium SLA tiers. Below it, when the vendor publishes one, a Support & Services section lists the entitlements layer with each promise tagged as a target, an entitlement, or — rarely — a real SLA. We never label a support response time as an SLA unless the vendor's own document attaches a credit to it. If you see "Target / SLO" next to a number, that's because the vendor's wording said so.

The data is open: see the dataset, the methodology, or suggest a correction.