DigitalOcean Credits per Product: Droplets Pay 100%, the Rest Pays by Tiers
September 7, 2026
DigitalOcean no longer has one SLA. The old single SLA page returns a 404; in its place sit per-product pages, each stamped with its own last-updated date, its own commitment, and its own credit schedule. The spread between them is the widest of any provider in this market: one product pays 100% of the affected resource's charge for any breach, another pays 100% of lost time at the hourly rate, and others pay tiered percentages. Filing a DigitalOcean claim against the wrong product page leaves real money unclaimed.
The product-by-product picture
The commitments and schedules below come from the product SLA pages themselves.
| Product | Commitment | Credit schedule | Claim window and route |
|---|---|---|---|
| CPU Droplets | 99.99% per instance | Below 99.99%: 100% of that Droplet's charge | Two billing cycles, email to success@digitalocean.com |
| Volumes Block Storage | 99.99% per month | Below 99.99%: 100% of lost time at the hourly rate | Three months from end of billing cycle, via support contact |
| DOKS control plane (HA enabled) | 99.95% | 10% below 99.95%, 25% below 99%, 100% below 95% | Three months, via support contact |
| Regional Load Balancers | 99.9% | 10% below 99.9%, 25% below 99%, 100% below 95% | Via support contact |
| Spaces | 99.9% per bucket | 10% below 99.9%, 25% below 99%, 100% below 95% | 24-hour written notice from downtime start, or the credit is forfeited |
Three of these stand out. The Droplet SLA is an instance-level commitment, which is rare: a single virtual machine carries a 99.99% promise, and any month below it pays the full charge for that Droplet. Volumes pays back the outage itself, 100% of lost time at the hourly rate, which makes the arithmetic refreshingly literal. And Spaces carries the harshest procedural rule in the big four: downtime credit only accrues from when you report the outage in writing within 24 hours of its start, and missing that notice forfeits the credit entirely, regardless of how bad the outage was.
The definitions decide the outcome
DigitalOcean's schedules only matter after the definitions are applied, and two of them do heavy lifting.
The five-minute floor. On Volumes and Spaces, Unavailability means all requests to the resource fail for more than 5 minutes, and monthly uptime is computed over 5-minute intervals. Sub-five-minute blips never enter the math. On Regional Load Balancers, Unavailability means five consecutive minutes or more of lost connectivity. If your incident history shows repeated 3-minute failures, your experience was real but the SLA never saw it.
The exclusion list. Scheduled maintenance and customer-initiated downtime are excluded across products, along with force majeure, third-party outages, and customer configuration errors. The DOKS exclusion list adds worker nodes (covered by the Droplets SLA instead) and anything outside the HA control plane. A claim that counts excluded minutes overstates the breach, and the reviewer subtracts them, which is why your evidence should isolate the provider-side failure window per the exclusions walkthrough.
One provider, five schedules, one clock that starts at 24 hours on Spaces. DigitalOcean's per-product split means the claim you file depends on which resource failed, and the Spaces notice rule does not forgive late detection.
Databases and App Platform, briefly
Two more product pages come up often enough to note. The Managed Databases SLA carries tiered commitments that start at 99.5% depending on the plan, a lower bar than Droplets, and the credits follow its own table rather than the Droplet 100% schedule. The App Platform SLA counts unavailability only after five consecutive minutes, so short 503 bursts from a build or a single failing dyno never accumulate into a claimable window.
The pattern to internalize: resource commitments are strong on compute and storage, weaker on platform services. If your stack depends on a platform product rather than raw Droplets, read that specific page before assuming the 99.99% number applies to you. The claims process is the same email or support route either way; only the threshold and the schedule change.
Filing, per product
The Droplet route is email: success@digitalocean.com, within two billing cycles of the downtime month, including the email address on the account, the affected resource details, and the outage dates and times. Most newer product SLAs (Volumes, DOKS, load balancers) route through the support contact instead, with a three-month window from the end of the billing cycle. In both cases DigitalOcean makes the final uptime determination in its own discretion; your probe logs and request logs are what their determination has to reckon with, per the evidence checklist.
Two practical notes. Because the Droplet commitment is per instance, a claim is per Droplet: one bad night that killed three Droplets is one claim covering three resources, paying 100% of each affected charge. And check the SLA version in force on the incident date, since the per-product pages carry separate last-updated dates and the older single SLA had different mechanics (the App Platform SLA, for example, counts unavailability only after five consecutive minutes).
UptimeAudit monitors DigitalOcean's status feeds alongside AWS, Azure, and Google Cloud, maps incidents to the product-level commitments above, and drafts the claim with the resource details attached. For a single-Droplet operator, the DIY version is one email template and a calendar entry; the 100% schedule makes it worth the ten minutes.