Azure Cosmos DB SLA Credits & Refunds

Cosmos DB downtime that's billed against your Azure subscription is usually creditable, but the SLA fine print determines how much. This guide walks through the Cosmos DB availability commitment Microsoft publishes, the exclusions that quietly disqualify many claims, and what FinOps teams do to systematically recover credits across an Azure tenant.

What this guide covers

• The official Azure Cosmos DB uptime commitment and credit tiers
• Which incidents qualify (and which exclusions silently disqualify claims)
• How to file a Cosmos DB credit request inside the Azure claim window
• Why manual claim recovery typically leaves money on the table

Frequently asked questions about Azure Cosmos DB SLAs

What is the typical SLA uptime guarantee for Azure Cosmos DB?

Cosmos DB offers tiered availability commitments depending on configuration: 99.999% read and write availability for accounts configured with multi-region writes, 99.999% read availability with 99.99% write availability for multi-region single-write accounts, and 99.99% for single-region accounts. Azure also publishes separate latency and throughput SLAs. If Azure fails to meet these commitments during a billing cycle, you are eligible to receive a portion of your Cosmos DB spend back as a service credit.

How do I claim Azure Cosmos DB SLA credits after an outage?

Submit a billing support request through the Azure portal: Help + Support → New support request → Issue type: Billing → Problem type: Service credit request. Within two months of the billing period in question, provide the affected Subscription ID and Resource ID, the start and end timestamps of the impacted period, your evidence (Azure Monitor logs, Resource Health alerts, or independent monitoring), and your calculated Monthly Uptime Percentage for Cosmos DB. Microsoft validates against its internal incident records before issuing the credit to your billing account.

What exclusions apply to the Azure Cosmos DB SLA?

Critically, HTTP 429 responses caused by exceeding provisioned RU/s (rate-limiting) are explicitly not considered downtime under the Cosmos DB SLA — they are the documented behavior when throughput is undersized.

Why is it difficult to get refunds for Cosmos DB outages manually?

Database SLAs get complicated because read availability, write availability, and replication health are often measured separately. A Cosmos DB outage that prevents writes but allows reads may qualify for a partial credit, or none at all, depending on the precise wording. The evidence required (query error rates, connection failures, replication lag from your monitoring) has to match the SLA's definition of unavailability exactly.

Related Azure SLA guides

Other Azure services creditable through the same portal-based billing request process:

• Azure SQL Database SLA credits — Database
• Azure Synapse Analytics SLA credits — Database
• Azure Virtual Machines SLA credits — Compute
• Azure Blob Storage SLA credits — Storage

Recover Azure credits without a portal grind

Azure billing support requests for Cosmos DB aren't difficult to file — they're tedious. Each one takes the same kind of subscription-ID, resource-ID, timestamp, and uptime-calculation packaging, repeated for every incident across every subscription you own.

Next Signal detects Cosmos DB SLA breaches across your Azure tenants, packages the credit request in the format Microsoft expects, and submits it. See how it works or start a free trial.