Every GPU cloud's pricing page says "uptime guaranteed." Almost none of them say guaranteed at what layer. A node going down for six minutes and a rack losing power for six hours can both get reported as "one incident" under the same SLA, and the credit you're owed for either one is usually a percentage of your monthly bill, not a number that reflects what a lost training run actually cost you. If you're about to wire a deposit on a GPU cluster reservation contract, the SLA clause is the part of the term sheet most worth reading twice.
This post breaks down what "guaranteed uptime" means at the node level versus the rack level, what the standard credit ladder actually pays out across major clouds, and how the published SLA language differs from AWS and Azure down to CoreWeave and Nebius. None of this replaces your own legal review. It's the due-diligence pass you do before that review, so you know which questions to ask.
'Guaranteed Uptime' Isn't One Number: Node-Level vs Rack-Level SLAs
A single provider can quote three different uptime numbers for the same cluster, depending on whether the SLA measures an individual node, a rack of nodes wired together, or the region-wide average across every instance it runs. AWS is the clearest public example: EC2's Monthly Uptime Percentage is 99.99% at the region level, for instances spread across two or more availability zones, but only 99.5% for a single instance running alone. Those are the same service, two different guarantees, and most buyers only see the higher number until they read the actual SLA document.
How Node-Level and Rack-Level SLAs Differ on GB200 NVL72-Class Racks
This gets more consequential on rack-scale systems like NVIDIA's GB200 NVL72, where dozens of GPUs share NVLink domains and a single failed component can take out more than one customer's workload. SemiAnalysis's ClusterMAX 2.0 report documents three distinct SLA models GPU clouds use on these systems:
| Model | Node-level guarantee | Rack-level guarantee | What you actually get |
|---|---|---|---|
| Dual-level | 99% | 95% | Full rack access, both thresholds apply |
| Node-only | 99% | None | Only 16 of 18 nodes; the rest serve as hot-spares or other tenants |
| Rack-only | None | 95% | Full 18-of-18 rack access, but no per-node floor |
As SemiAnalysis puts it: "Individual nodes must have a 99% uptime, but a rack (defined as 16 of the 18 nodes, or 64 of 72 GPUs) has a lower SLA at 95%." That gap between 99% and 95% is not a rounding error. At 99% uptime you're looking at roughly 7 hours of downtime a month; at 95%, more like 36 hours. A dual-level SLA is the strongest of the three because both numbers apply at once, but it's also the hardest one for a provider to actually hit, which is exactly why some contracts quietly drop to node-only or rack-only instead. Ask which of the three models you're signing, by name, before you assume "SLA" means the strongest version.
Why the Failure Rate Gets Worse as Clusters Get Bigger
The reason rack-level SLAs sit lower than node-level ones isn't contract-writer pessimism, it's math. A Meta-led analysis of roughly 150 million A100 GPU-hours across two research clusters found mean time between failures collapsing as job size grows: about 7.9 hours at 1,024 GPUs, down to about 1.8 hours at 16,384 GPUs. More GPUs in a job means more components that can fail, and a training run only needs one to go down to stall.
The damage concentrates on exactly the workloads a reservation contract is meant to protect. In the same Meta research, failures affected only 0.2% of jobs overall but consumed 18.7% of total cluster runtime, because the largest, longest-running jobs get hit disproportionately hard and each failure wastes hours of GPU time before a checkpoint can restart it. Meta's own published research on a separate 16,000-GPU, 54-day training job, cited in Nebius's writeup on cluster reliability, found hardware issues caused 78% of unexpected interruptions, versus 12.9% from software bugs. That ratio matters for your due diligence: an SLA that only covers "our platform being down" and excludes individual node hardware failures is excluding the failure mode that actually dominates at scale.
What SLA Credits Actually Cover (and What They Don't)
An SLA credit is a rebate on your bill for the affected resource during a defined measurement window, calculated as a percentage tied to how far uptime fell below the promised threshold. It is not a payout sized to what the outage cost you. That distinction is the single most important thing to understand before you treat a published SLA percentage as a risk mitigant for a multi-week training run.
The Standard Credit Ladder Across Major Clouds
Every major provider uses some version of a tiered credit ladder: the worse the uptime miss, the higher the credit percentage, capped well below 100% except at the very bottom tier.
| Provider | SLA | Credit tiers |
|---|---|---|
| AWS EC2 (single instance) | 99.5% | 10% (99.0%-<99.5%), 30% (95.0%-<99.0%), 100% (<95.0%) |
| AWS EC2 (region, multi-AZ) | 99.99% | 10% (99.0%-<99.99%), 30% (95.0%-<99.0%), 100% (<95.0%) |
| Oracle OCI Compute | 99.99% | 10% (99.0%-<99.9%), 25% (95.0%-<99.0%), 100% (<95.0%) |
| DigitalOcean GPU Droplets | 99% | 10% (95%-<99%), 25% (90%-<95%), 50% (<90%) |
| CoreWeave (Object Storage only) | 99.9% | 10%-100% depending on severity |
Every one of these credits is future-use account credit, not a cash refund or invoice reduction, applied against your next bill. And the fine print on claiming it varies more than the headline percentage does. DigitalOcean, for example, requires written notice within 24 hours of the incident or you forfeit the credit entirely, and any unused credit you do receive expires after 90 days. If your team doesn't have a process for filing an SLA claim within a day of an outage, the percentage on the pricing page is closer to theoretical than real.
Why Credits Are the 'Exclusive Remedy', Not Compensation for a Lost Training Run
Nebius's SLA terms state the principle plainly: "Compensation is the sole and exclusive remedy and indemnification to Customer for Nebius' failure to comply with the warranted Service Level." That single sentence is standard across the industry, not a Nebius-specific term, and it's worth reading literally. It means the credit is the entire remedy, contractually. You are not entitled to separately claim the cost of a stalled training run, missed launch date, or SLA-driven customer escalation on your own end. Nebius's terms also don't state the actual uptime percentage in the main agreement; they point to a separate linked page per service, which is itself worth checking before you assume a number that isn't written where you're looking.
Run the math on what this actually protects. If a dedicated 8-GPU cluster costs roughly $15,000 a month, even a 30% credit for a serious uptime miss is around $4,500, refunded as future compute credit. Compare that to what real downtime costs a business: Oxford Economics, cited in our breakdown of the October 2025 AWS outage, puts the average cost of unplanned downtime at roughly $9,000 per minute, $540,000 per hour, across the organizations it surveyed. An SLA credit is not designed to close that gap, and no provider's terms claim that it does. It's a bill adjustment, not insurance.
If your workload is customer-facing rather than a training run, the uptime threshold you actually need may be lower than "guaranteed" and easier to hit with a shared pool instead of dedicated capacity. Our multi-tenant LLM serving guide maps tenant SLA requirements above 99.5% uptime to when dedicated instances are worth the premium over a shared inference pool, which is a cheaper way to solve the same reliability problem for workloads that don't need a full reservation.
A Provider-by-Provider Look at Published SLA Language
The gap between what "SLA" implies and what a provider actually commits to in writing is wide enough that it's worth checking each one directly rather than trusting a comparison chart, including ours below. Treat this as a starting point for your own read of the current terms.
Hyperscalers: AWS, Azure, GCP, Oracle
AWS's EC2 SLA splits cleanly by deployment shape: 99.99% at the region level across multiple availability zones, 99.5% for a single instance running alone. Credits run 10%, 30%, or 100% of your bill depending on how far uptime fell.
Azure's single-instance VM SLA depends on the disk type attached to it: 99.9% on Premium or Ultra SSD, 99.5% on Standard SSD, and just 95% on Standard HDD. Multi-VM availability sets get 99.95%, and availability-zone deployments get 99.99%. The detail most buyers miss: Azure's own reliability documentation classifies its GPU VM series, including NCv3, NDv2, NDasrA100_v4, NDm_A100_v4, and NVv3/NVv4, under "Strategic," the lowest of Azure's three service-availability tiers (foundational, mainstream, strategic). That tier governs regional rollout and demand-driven availability commitments, not the uptime SLA percentage itself, but it's a signal worth knowing: your GPU instances sit in Azure's least broadly guaranteed availability category, not its most mature one.
Oracle Cloud Infrastructure Compute, including bare-metal GPU shapes, carries a 99.99% Monthly Uptime SLA in multi-availability-domain regions, with credit tiers of 10% (99.0%-<99.9%), 25% (95.0%-<99.0%), and 100% (below 95.0%).
Google Cloud's Compute Engine SLA follows the same single-instance-versus-region split as AWS, and its own SLA terms note that the Monthly Uptime Percentage and any resulting Financial Credit are calculated per project, per region, or per single instance, capped at what you spent on the affected resource that month. As with the others, check the exact current percentage on Google's SLA page directly since GCP has historically tiered the number by deployment configuration rather than publishing one flat figure for every GPU instance type.
Neoclouds: CoreWeave, Lambda, Nebius, Crusoe, DigitalOcean
On CoreWeave's own public docs pages, the only published numeric uptime SLA is 99.9% monthly uptime, and it applies to AI Object Storage, not GPU compute. Its Reserved Instance and Flex Reservation capacity plans documentation describes a capacity guarantee, meaning your allocation is held for you regardless of platform-wide demand, but attaches no uptime percentage or credit remedy to that guarantee on the page itself. That's a meaningful gap if you're assuming "reserved" implies an uptime number the way it does on a hyperscaler. It isn't the whole story, though: SemiAnalysis's ClusterMAX 2.0 report notes that CoreWeave is among the "top providers" now offering 99% rack-level uptime guarantees with penalties attached on GB200 NVL72 systems, which reads as a negotiated term in custom contracts rather than a standing figure on a public SLA page. If you're evaluating CoreWeave specifically, ask for that rack-level number in writing, since it isn't published the way AWS's or Oracle's compute SLA is.
Lambda's cloud terms of service likewise contain no numeric uptime SLA or service credit language for its GPU cloud instances as of this writing. If uptime commitments matter for your workload, that's a term you'd need to negotiate directly rather than one already sitting in the standard agreement.
Nebius, as covered above, defers the actual uptime percentage to a separate per-service page rather than stating it in the main SLA, and treats compensation as the sole and exclusive remedy for a breach.
Crusoe's own cloud page features a customer, Windsurf, citing a 99.98% cluster uptime figure for its H100 GPUs. That's a testimonial about one customer's experience, not a contractual SLA percentage published by Crusoe for GPU compute generally, and the two shouldn't be conflated when you're evaluating what a contract actually commits to.
DigitalOcean's GPU Droplet SLA is the most fully specified of the group, on paper: 99% uptime, credit tiers of 10% (95%-<99%), 25% (90%-<95%), and 50% below 90%, paid as future-use credit only. The catch is entirely in the claim mechanics: you must notify DigitalOcean in writing within 24 hours of the downtime or forfeit the credit, and any credit issued expires if unused within 90 days.
Where Spheron's Published SLA Fits
Spheron publishes a 99.99% uptime SLA on dedicated, non-interruptible on-demand GPU instances, meaning capacity that can't be reclaimed by the provider the way spot instances can. Its reserved-commitments product is framed separately as "100% Guaranteed" allocation, locking specific GPU models and quantities to your project timeline, but that's the capacity-guarantee side of the document, not a separately stated uptime percentage. It's the same gap this post flags on CoreWeave's Reserved Instances above, and it's worth naming here rather than glossing over it: if you're evaluating reserved capacity on any provider, including Spheron, ask for the uptime number in writing rather than assuming "guaranteed" already covers it. If you're weighing Spheron against CoreWeave specifically, our Spheron vs CoreWeave comparison covers the pricing gap alongside this same rack-versus-node SLA structure. And if you're using our top 10 GPU cloud providers roundup to shortlist vendors, note that a blanket claim of "99.99% SLA on dedicated instances" across every specialist provider doesn't hold up against CoreWeave's own published terms, which is exactly the kind of gap this post exists to close.
Capacity Guarantee SLA vs Uptime SLA: Don't Confuse the Two Documents
These are two different promises, frequently bundled under the same word "guaranteed," and conflating them is the most common mistake we see in reservation contract review. A capacity guarantee SLA promises that a defined allocation of GPUs is held for you, reserved against platform-wide demand, for the term of your contract. An uptime SLA promises that the GPUs you're allocated are actually running and reachable for a defined percentage of time, with a credit remedy if they aren't.
A provider can satisfy a capacity guarantee in full, your 64 GPUs are sitting there with your name on them, while badly missing an uptime SLA, because half of those GPUs are down for hardware faults on a given day. CoreWeave's capacity plans are the clean example: the documentation is explicit about capacity guarantees for Reserved Instances and Flex Reservations, and equally silent on any attached uptime number. If your term sheet only uses the word "guaranteed" once, ask which of the two documents it's actually describing, and get the other one added in writing if it's missing. Our full reservation contract negotiation guide covers the capacity-guarantee side of this in more depth, including the exact wording to push for on capacity that isn't backed by a stated percentage.
Questions to Ask Before You Sign a Reservation Contract
Confirm you have written answers to all of the following before you commit capital to a term you can't unwind:
- What layer does the uptime SLA measure? Node, rack, or region-wide, and what's the exact percentage at each layer you're actually buying.
- Is this a dual-level, node-only, or rack-only SLA if you're on a rack-scale system like GB200 NVL72? Ask by name, don't infer it from the word "guaranteed."
- What's the credit ladder, tier by tier, and is it capped at 100% of your bill for the affected resource or something lower?
- Is the credit cash, invoice reduction, or future-use account credit only? Most are the latter, and it changes the real value of the remedy.
- What's the claim window and notice requirement? Some providers, like DigitalOcean, require written notice within 24 hours or the credit is forfeited entirely.
- Does unused credit expire? And if so, on what timeline.
- Is the credit the sole and exclusive remedy, contractually, or can you negotiate a carve-out for extended outages during active training runs?
- Is there a separate capacity guarantee SLA, and does it specify a percentage and remedy, or just the word "guaranteed" with nothing attached?
- Does the provider publish this SLA at all, or is it something you have to negotiate into a custom agreement? Several neoclouds, per the survey above, don't have a standing uptime SLA for GPU compute in their default terms.
None of these questions require a lawyer to ask, though your legal team should review the actual language once you have answers. The providers with the strongest published SLAs make it easy to find these numbers before you ask; the ones that don't are telling you something too.
Spheron publishes a 99.99% uptime SLA on dedicated on-demand instances and frames reserved capacity commitments as "100% Guaranteed" allocation, a capacity guarantee, not a separately stated uptime number, so you know exactly which document you're reading before you sign.
Frequently Asked Questions
A node-level SLA guarantees the uptime of individual servers, typically around 99%, and can look strong on paper even while your whole cluster is degraded. A rack-level SLA guarantees uptime across the full rack (on GB200 NVL72-class systems, that's usually defined as 16 of 18 nodes, or 64 of 72 GPUs), and per SemiAnalysis's ClusterMAX 2.0 report, rack-level SLAs typically sit lower, around 95%, because keeping every node in a tightly coupled system up at once is a harder bar to clear than keeping any single node up.
No. SLA credits are almost universally structured as a percentage of your monthly bill for the affected resource, refunded as account credit, not as compensation for lost compute time, missed deadlines, or the cost of restarting a training job from checkpoint. Nebius's SLA terms state directly that compensation is the sole and exclusive remedy for a breach. If a multi-week training run gets interrupted, the credit you're owed is calculated off your bill, not off what the interruption actually cost you.
Not on its public docs pages. CoreWeave's only published numeric uptime SLA is 99.9% monthly uptime on its AI Object Storage product. Its capacity plans documentation for Reserved Instances and Flex Reservations describes a capacity guarantee, meaning the nodes are held for you, but does not attach an uptime percentage or a credit remedy to that guarantee on the page itself. SemiAnalysis's ClusterMAX 2.0 report notes CoreWeave is among the providers now offering 99% rack-level uptime guarantees with penalties on GB200 NVL72 systems, but that reads as a negotiated contract term rather than a standing published figure, so ask for it in writing.
Treat them as two different documents. A capacity guarantee SLA promises you'll get access to a defined GPU allocation; an uptime SLA promises that allocation will actually be running and reachable. Spheron, for example, publishes a 99.99% uptime SLA on dedicated on-demand instances, while its reserved capacity commitments are framed as '100% Guaranteed' allocation, a capacity guarantee rather than a separately stated uptime percentage. Ask any provider for both numbers in writing, not just one.