Azure SQL Database SLA Credits & Refunds

Azure's SLA framework treats database services like SQL Database as a measurable commercial commitment, not a courtesy. If SQL Database falls below its monthly uptime target, you can claim credits — but only if you file through the Azure portal with the right billing evidence. This guide covers the exact SQL Database thresholds, exclusions, and claim procedure.

What this guide covers

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

Frequently asked questions about Azure SQL Database SLAs

What is the typical SLA uptime guarantee for Azure SQL Database?

Azure SQL Database commitments depend on the service tier: 99.995% uptime for Business Critical and Premium tiers configured with zone-redundant deployments, 99.99% for Business Critical/Premium single-zone and for General Purpose tiers, and 99.99% for Hyperscale (with at least one secondary replica). If Azure fails to meet this commitment during a billing cycle, you are eligible to receive a portion of your SQL Database spend back as a service credit.

How do I claim Azure SQL Database 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 SQL Database. Microsoft validates against its internal incident records before issuing the credit to your billing account.

What exclusions apply to the Azure SQL Database SLA?

Notably, query failures caused by hitting DTU/vCore resource governance limits, transient connection errors that succeed on retry (per Microsoft's documented retry guidance), and downtime in the Basic tier or Hyperscale without a secondary replica are excluded.

Why is it difficult to get refunds for SQL Database outages manually?

Database SLAs get complicated because read availability, write availability, and replication health are often measured separately. A SQL Database 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 Cosmos DB 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 SQL Database 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 SQL Database 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.