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. status.claude.com 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.
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
A client asks for a "99.9% SLA" on their AI assistant with no further detail. What must the architect clarify first?
"99.9% is a standard SLA number that covers both dimensions" - a single number cannot certify two independently-failing dimensions, and no vendor-published figure is a contractual SLA on its own regardless.An architect quotes the status page's 99.57% 90-day API uptime figure to a customer and says, "this is our SLA." Separately, a colleague quotes Priority Tier's 99.5% figure the same way. What's wrong with both statements?
"whichever number is higher is the more credible SLA to quote" - neither is a contractual SLA at all, so comparing their size misses the actual error.A team commits to "95% accuracy" as their SLA and points to Anthropic's published uptime figures as evidence they'll hit it. What is the error?
"high published uptime is a reasonable proxy for output quality" - the two dimensions fail independently in a nondeterministic system.A prospect, as a brand-new customer, wants to buy guaranteed-capacity Priority Tier access today. What does the architect need to know before promising it?
"Priority Tier can be self-serve purchased like Standard tier" - that is exactly the stale assumption current docs correct.An architect sets an output-quality bar once at launch and never revisits it. Six months later, usage patterns have shifted and the eval score has quietly dropped. What is missing?
"a one-time launch eval is sufficient once the system passes it" - that treats the quality SLA as static when it needs continuous monitoring.A stakeholder cites Anthropic's published 90-day observed uptime figure as if it were their contractual SLA, with no independent monitoring of their own workload and no separately negotiated agreement. What risk should the architect flag?
"a published uptime figure functions as the contractual SLA once cited to the customer" - citing a number doesn't make it contractual, and it still needs independent validation either way.Frequently asked
Does Anthropic publish a standard number for output-quality SLAs?
Can I still buy Priority Tier capacity today as a new customer?
Is the 99.57% status-page number or the Priority Tier's 99.5% target a contractual SLA?
Work this with your AI
Work this concept hands-on with Claude Code, Codex, or claude.ai. Copy a prompt, paste it into your assistant, and practise in tandem. Each one keeps you active (explain it back, get drilled, or build) rather than just reading.
- Drill it like the exam (scenario MCQs)Practice in the exam's scenario-MCQ format with trap awareness.
- Explain it back (Feynman)Build durable, transferable understanding of a concept you can half-state.
- Test me, adapting the difficultyActive recall practice on a concept you think you know.
- Check my prerequisites firstBefore studying a concept that keeps not sticking.
- Find the high-leverage 20%When a domain feels too big and you are short on time.