DigitalOcean SLA Credits: The Real Commitments, Deadlines, and Gotchas
August 6, 2026
DigitalOcean owes you a service credit whenever a product misses its uptime number, and for Droplets the deal is refreshingly simple: any month a Droplet dips below 99.99% uptime earns a credit of 100% of that Droplet's charges. The problem is that "the DigitalOcean SLA" does not exist as one document. It is a stack of per-product agreements with different commitments, different credit schedules, and different deadlines, and one of them, Spaces, requires you to report the outage in writing within 24 hours or lose the credit entirely. Here are the exact numbers from the current SLA pages and how to file when one is missed.
There is no single DigitalOcean SLA
DigitalOcean publishes a separate SLA for each product: CPU and GPU Droplets, Volumes, Spaces, Container Registry, Managed Databases, App Platform, Kubernetes, both load balancer types, NAT Gateway, and Marketplace. Uptime is measured per billing cycle, and for most products per individual resource (each Droplet, each bucket, each database cluster), never across your whole account in aggregate.
The commitments most accounts actually run against:
| Product | Uptime commitment | Measured on |
|---|---|---|
| Droplets | 99.99% | each individual Droplet |
| Volumes block storage | 99.99% | volumes on the account |
| Managed Databases, with standby node | 99.95% | each cluster |
| Managed Databases, no standby node | 99.5% | each cluster |
| App Platform | 99.95% | each app component instance |
| Kubernetes control plane, HA enabled | 99.95% | each cluster |
| Spaces object storage | 99.9% | each bucket |
| Container Registry | 99.95% | each image resource |
What those percentages allow
Droplet uptime is calculated as (total minutes in the month minus minutes of unavailability) divided by total minutes. Convert the commitments into minutes and the stakes get concrete:
| Commitment | Downtime allowed in a 30-day month | In a 31-day month |
|---|---|---|
| 99.99% | 4.3 minutes | 4.5 minutes |
| 99.95% | 21.6 minutes | 22.3 minutes |
| 99.9% | 43.2 minutes | 44.6 minutes |
| 99.5% | 216 minutes | 223 minutes |
A single 30-minute blip puts any Droplet below its 99.99% commitment for the month. You do not need a headline-grabbing outage to be owed money, just one incident that clears the unavailability bar.
What counts as downtime, and what does not
Read the definitions before you file, because they are narrower than "the site was down."
For Droplets, unavailability is loss of connectivity to the Droplet over its public, reserved, or private IP, or loss of read/write access to its root disk, caused by a failure of DigitalOcean infrastructure. Excluded: scheduled maintenance, customer-initiated downtime, force majeure, account restrictions, and anything that traces back to your application code or configuration. Your app returning 500s is not DigitalOcean downtime. The Droplet SLA also hands off to other documents: DOKS control planes and managed database clusters are covered by their own SLAs.
Managed Databases count a cluster as unavailable when it has no external connectivity for more than five minutes. Spaces measures 5-minute intervals in which a bucket has no external accessibility. App Platform requires five consecutive minutes of failed ingress or execution before the clock starts.
The Spaces 24-hour rule deserves its own paragraph. Downtime starts accruing only when you report it or acknowledge a proactive report from DigitalOcean, and you must notify them in writing within 24 hours of the downtime starting. Miss that notice and the right to the credit is forfeited, no matter how visible the outage was.
The credit schedules
Credits are a percentage of the affected resource's charges for the month. The tiered products use the same banding: tier 1 is below the commitment but at least 99.0% (for Managed Databases without a standby node, tier 1 starts below 99.5%), tier 2 is 99.0% down to 95.0%, and tier 3 is below 95.0%.
| Product | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Droplets | 100% (any breach of 99.99%) | — | — |
| Volumes | 100% of lost time at hourly rate | — | — |
| Managed Databases, standby | 10% | 25% | 100% |
| Managed Databases, no standby | 10% | 25% | 100% |
| App Platform | 10% | 30% | 100% |
| Kubernetes control plane | 10% | 25% | 100% |
| Spaces | 10% | 25% | 100% |
| Container Registry | 10% | 25% | 100% |
Droplets stand out because there are no tiers: any breach of the 99.99% commitment is worth 100% of the affected Droplet's charges. That sounds generous until you read the scope clause. Credits apply only to the specific resources that were down, not to your account. A $6 Droplet earns $6.
Deadlines: read the one for your product
Every SLA requires you to file, and none of them will remind you:
| Product | Deadline | Channel |
|---|---|---|
| Droplets | within two billing cycles of the outage month | success@digitalocean.com |
| Managed Databases | end of the second billing cycle after the failure | support portal |
| App Platform | end of the second billing cycle after the failure | support portal |
| Volumes | within three months of the end of the billing cycle | support portal |
| Kubernetes | within three months of the end of the billing cycle | support portal |
| Spaces | 30 days after the end of the billing cycle, plus the 24-hour notice rule | support portal |
| Container Registry | 30 days after the end of the billing cycle | support portal |
The one thing to remember: credits are claim-only, every product has its own deadline, and the shortest window belongs to Spaces, which pairs 30 days with a 24-hour notice requirement. Assuming the deadline is how credits go unclaimed.
An outage in March must reach DigitalOcean by the end of May for Droplets (two billing cycles after the March cycle closes) but by April 30 for Spaces and Container Registry (30 days after the end of March's cycle). File early. The number that decides everything, monthly uptime percentage, is calculated by DigitalOcean in its own good-faith determination, so your evidence needs to line up with the incident, not argue about it.
How to file
For Droplets, email success@digitalocean.com with the email address on the account, the affected Droplet details, and the outage dates and times. For everything else, open a ticket at the support portal (cloudsupport.digitalocean.com). The SLAs specify what the claim must contain: the affected resource (Droplet ID, cluster name, bucket name, app component), the dates and times of each unavailable period, and request logs that document the outage. Pull the logs before you file, not after support asks for them. Approved credits are issued within one billing cycle of confirmation.
A few limits apply across products. Credits are applied to future invoices, are non-refundable and non-transferable, and several of the SLAs (App Platform, Managed Databases, Spaces, Container Registry) only issue credits above $1. Spaces and Container Registry credits expire 90 days after they are issued.
A worked example
Say a $24/month Droplet in NYC3 loses connectivity for 30 minutes in July. July has 44,640 minutes, so uptime lands at about 99.93%, below the 99.99% commitment. The credit is 100% of that Droplet's charges for the month:
| Monthly Droplet spend | July uptime | Credit | Payout |
|---|---|---|---|
| $6 | 99.93% | 100% | $6 |
| $24 | 99.93% | 100% | $24 |
| $120 | 99.93% | 100% | $120 |
The same math explains why most small accounts never bother: per-resource credits on cheap resources are small, and filing takes the same effort whether the credit is $6 or $600. The accounts that collect are the ones that file monthly, across the whole fleet, on every product with a breached commitment.
The real work is tracking
Filing is fifteen minutes of copy-paste once you know an incident happened, which product it hit, and whether the monthly math crossed a tier. Tracking is the job: the status page does not email you that money is owed, deadlines differ per product, and a 24-hour notice window will close before your Monday standup. That is the gap UptimeAudit closes: it watches provider status pages, matches incidents to the services you run, and drafts the credit claim when a threshold is crossed, so you review and submit before the window closes.
What to do this week
Open the SLA page for the product that had an incident on your account last month (the index lives at digitalocean.com/sla). Check the commitment against the month's uptime, note the deadline for that specific product, pull the request logs for the outage window, and file through the channel in the table above. If the outage happened last month, the Droplet window is still open, and Spaces and Container Registry are already tight. The deadline is the only part of this that moves on its own.