TLDR
A Claude-based system's "SLA" is not one number - an architect has to keep at least three infrastructure-side concepts straight, plus a fourth for quality: observed historical uptime (a retrospective status-page record, e.g. 99.57% API / 99.51% Claude Code over a trailing 90 days), a service tier's stated target (Priority Tier "targets 99.5% uptime," an aspirational figure tied to a paid capacity commitment, not a penalty-bearing guarantee), and an actual contractual SLA (a separately negotiated legal commitment with remedies, never published by Anthropic as a percentage) - plus output-quality reliability (is the answer good enough), which has no vendor-published number at all and is negotiated per project against your own eval suite. The trap is treating the observed number or the tier target as if either one were itself a binding SLA, or as if either certifies output quality.
What it is
A Claude-based system's "SLA" is not one number - an architect has to align stakeholders on separate concepts that traditional software conflates: on the infrastructure side alone there are three different things (observed historical uptime, a service tier's stated target, and an actual contractual SLA), and none of the first two is the third. Layered on top is a wholly separate dimension, output-quality reliability (is the answer good enough). These fail independently: a nondeterministic system can be fully "up" while producing unacceptable output, so no infra number, observed or targeted, can stand in for output quality, and neither can stand in for a real contractual commitment either.
Anthropic publishes real, checkable infrastructure-level data an architect can start a negotiation from - live observed uptime at status.claude.com and three named API service tiers, one of which states an uptime target. Neither of those is a contractual SLA: a genuine contractual SLA, the number an enterprise customer can actually hold Anthropic to with remedies if missed, has to be separately negotiated into the customer's own agreement and is not published as a percentage anywhere. The output-quality half has no vendor number at all: it is negotiated project-by-project against the project's own eval results, and this is the half most often left implicit when a team reuses a generic "SLA template."
How it works
Start from a real, checkable OBSERVED baseline - and treat it as a retrospective record, not a promise. Anthropic publishes live, historical uptime for each product surface at status.claude.com - at time of writing, 99.57% API uptime and 99.51% Claude Code uptime over a trailing 90-day window. This describes what already happened; the status page makes no claim it will hold going forward, and the number moves. Citing it AS the SLA is a category error - it's a data point for a negotiation, not the contract itself.
A service tier's published number is a TARGET, not a contractual guarantee - and it is a different thing again from an observed uptime figure. Standard is the default tier with best-effort availability, no percentage attached at all. Priority Tier, available only to organizations with an existing capacity commitment, "targets 99.5% uptime with prioritized computational resources" per Anthropic's own service-tier docs - "targets" is doing real work there: it's a stated operating goal tied to a paid capacity commitment, not a penalty-bearing SLA guarantee. As of current docs, new Priority Tier capacity commitments are no longer available for purchase for new customers; existing commitments continue through their contract end date, and new guaranteed-capacity needs route through direct sales rather than self-serve tier selection. Batch is async, has no latency SLA, and costs less.
A CONTRACTUAL SLA is a third, distinct thing from either number above, and Anthropic does not publish one as a percentage. Both the observed 90-day uptime and a service tier's target describe Anthropic's own operating characteristics; neither is, by itself, a legally binding commitment with remedies (service credits, termination rights) if missed. A real contractual SLA has to be separately negotiated into the customer's own agreement, typically through direct sales/legal - it is not something to infer from the status page or the service-tier docs. Citing the observed figure or the Priority Tier target as if it were the signed contractual SLA confuses a historical record and an aspirational target with a legal commitment.
The output-quality SLA has no vendor-published number at all - it is project-derived. Accuracy thresholds, hallucination-rate ceilings, and the confidence band that triggers escalation to a human all have to come from the project's own eval suite and get negotiated with the stakeholder as a project-specific bar. This is the part most often skipped when a team reaches for a generic SLA template that only covers uptime.
A feedback loop keeps all of these visible as real traffic shifts. Recurring eval-score reviews with the stakeholder, not a one-time launch gate, are what catch an output-quality bar quietly slipping after usage patterns change; observed uptime is monitored continuously by definition (status dashboards), but a customer's actual contractual terms and the quality bar both need that same discipline built in deliberately, not assumed from a public status page.
The trap is treating any one of these as interchangeable with the others: (1) OBSERVED historical uptime on the status page (retrospective, no forward commitment), (2) a service-tier TARGET like Priority Tier's 99.5% (aspirational, tied to a paid capacity commitment, still not a penalty-bearing guarantee), (3) an actual CONTRACTUAL SLA (a separately negotiated legal commitment with remedies, never published as a percentage anywhere), and (4) output-quality/accuracy reliability (project-specific, eval-derived, no vendor number exists). CCA-P tests whether a candidate keeps a historical record, an aspirational target, and a binding legal commitment straight, on top of the classic infra-vs-quality split - plus whether the candidate knows current Priority Tier purchase mechanics rather than an outdated self-serve assumption.
Where you'll see it
Retail AI shopping assistant
A requested "99.9% SLA" gets split into infrastructure availability (Anthropic's published baseline plus the client's own retry/failover design) and output-quality reliability (95% eval pass rate, alert and route-to-human below that), reviewed weekly rather than gated once at launch.
Priority Tier negotiation for a high-volume agent
An architect scoping a high-volume support agent checks whether the client's projected token volume justifies opening a Priority Tier capacity conversation with sales, versus staying on Standard tier's best-effort availability.
Side-by-side
| SLA-adjacent number | What it actually is | Example figure | Is it contractual? |
|---|---|---|---|
| Observed infrastructure uptime (status.claude.com) | A retrospective historical record, not a forward-looking promise | 99.57% API / 99.51% Claude Code (90-day snapshot) | No - Anthropic publishes it, but states no forward commitment |
| Priority Tier capacity target | An aspirational operating target tied to a paid capacity commitment | "Targets 99.5% uptime"; new commitments route through direct sales, not self-serve | No - stated as a target, not a penalty-bearing SLA |
| Contractual SLA (financial remedies / credits) | A legally binding commitment, separately negotiated into the customer's own agreement | No vendor-published percentage - negotiated case-by-case | Yes, but only if actually negotiated - never inferred from public docs |
| Output-quality reliability | Your project's own eval suite | e.g. "95% of responses pass our accuracy eval" | Negotiated project-by-project - no vendor number exists |
| Escalation policy | The confidence band below which output routes to a human | e.g. "below a stated eval-suite confidence, escalate" | Negotiated alongside the output-quality SLA |
Question patterns
6 V2 questions wired to this concept. Tap an answer to check it instantly - you'll see whether it's right and why - then expand the full breakdown for the mental model and all four rationales.
A manufacturer wants an AI system to hit a hard 99.9% uptime SLA for a production-line defect-detection assistant, while also wanting the lowest possible per-inference cost. Both requirements are stated as "must-have." How should the architect resolve this at the design stage?
Frequently asked
Showing 3 of 3 questions