By Amit & Animesh, Co-founders, Nuvika Technologies
Your cloud provider made you a promise. It’s buried in the SLA document you signed but probably never read.
The promise says: if we fail to deliver the uptime we committed to, you get credits back.
AWS, Azure, and GCP all make these commitments. And all three regularly miss them — outages, degraded performance, regional failures. When they do, you’re owed money.
But here’s the catch that costs companies thousands every year: they don’t tell you. There’s no alert. No automatic refund. No email saying “sorry, here’s your money back.”
You have to notice the breach. Collect the evidence. File the case. Track the credit. And do it all within a tight deadline.
Most companies never do. The money just stays with the provider.
This guide covers everything you need to know about SLA credit recovery across all three major clouds — what’s promised, what happens when they miss it, how to claim what you’re owed, and why almost nobody does.
What Cloud Providers Actually Promise
AWS SLA Commitments
AWS publishes individual SLAs for each service. The commitments vary:
EC2: 99.99% uptime for instances spread across multiple AZs, 99.5% for single-instance deployments.
S3: 99.9% availability for Standard storage.
RDS Multi-AZ: 99.95% uptime.
Lambda: 99.95% uptime.
ECS/Fargate: 99.99% when running across multiple AZs.
When AWS misses these targets, the credit structure is typically tiered. For EC2 Multi-AZ, if monthly uptime drops below 99.99% you get a 10% service credit; below 99.0% gets you 30%; below 95.0% gets the maximum 100% credit.
The key detail most people miss: AWS measures uptime at the region level, not the individual instance level. A single instance going down doesn’t trigger an SLA breach — the service must be unavailable or degraded across the region.
Azure SLA Commitments
Azure’s SLA structure is similar but with some important differences:
Virtual Machines: 99.99% for VMs deployed across Availability Zones, 99.95% for VMs in Availability Sets, 99.9% for single-instance VMs with Premium SSD.
Azure SQL Database: 99.99% for Business Critical and Premium tiers.
App Service: 99.95% uptime.
Azure Kubernetes Service: 99.95% for clusters using Availability Zones, 99.9% without.
Azure’s credit tiers are generally: below the SLA target gets 10% credit, below 99% gets 25%, below 95% gets 100%.
A critical Azure-specific detail: Azure does not proactively notify customers when SLAs have not been met. This is explicitly stated in Microsoft’s own documentation. It’s entirely up to you to detect, prove, and claim.
GCP SLA Commitments
Compute Engine: 99.99% for instances spread across multiple zones, 99.5% for single-zone.
Cloud SQL: 99.95% for regional instances, 99.99% for regional instances with high availability.
BigQuery: 99.99% availability.
Cloud Run: 99.95% uptime.
GCP’s credit structure follows a similar tiered pattern: 10-15% credits for minor breaches, up to 50% for major ones.
The critical GCP-specific constraint: you must file a claim within 30 days of becoming eligible. That’s the tightest deadline of any major cloud provider. Miss the window and the credit is gone forever.
Why Almost Nobody Claims These Credits
We’ve seen this pattern for over two decades across hundreds of companies. The reasons are consistent:
Nobody’s watching. SLA monitoring isn’t anyone’s job description. The engineering team monitors application health, not provider uptime. The finance team sees the bill but has no visibility into whether the provider delivered what was promised.
The evidence burden is on you. It’s not enough to say “our app was down.” You have to prove that the provider’s service was degraded, that it fell below the SLA threshold, and that it impacted your workloads. This requires correlating your monitoring data with the provider’s service health data — a non-trivial exercise.
The deadlines are tight and different. Azure gives you 2 months from the end of the billing period. GCP gives you just 30 days. AWS gives you until the end of the second billing cycle after the incident. If you miss these windows, the credits are forfeited permanently. No exceptions.
The amounts seem small individually. A 10% credit on one service for one month might be a few hundred rupees. Not worth the effort, right? But multiply that across dozens of services, hundreds of instances, and twelve months — it adds up to lakhs per year.
Nobody knows the process. Each provider has a different claim mechanism. AWS requires opening a case in the Support Center. Azure requires submitting through the Azure portal. GCP requires a support case. The processes aren’t standardized, and the documentation is buried in legal pages nobody reads.
The Real Cost of Not Claiming
Let’s do some rough math.
A company running a mid-size Azure environment — 200 VMs across availability zones, several SQL databases, App Services, and supporting infrastructure — might have a monthly cloud bill of ₹20-30 lakhs.
Azure’s major cloud services experience measurable degradation on average 4-6 times per year (based on publicly reported incidents on the Azure Status History page). Not all of these will breach SLA thresholds, but some will.
If even 2-3 of those incidents qualify for a 10% service credit on affected services, that could represent ₹50,000-₹2,00,000 per year in unclaimed credits — from one provider alone.
Scale that across three clouds and multiply by companies that have been running for 3-5 years without ever checking. The unclaimed credits across the industry run into crores.
The money is already owed. It’s already allocated in the provider’s accounting. They simply don’t remind you to ask for it.
How to Claim SLA Credits Manually
If you want to do this yourself, here’s the process for each provider:
AWS Claim Process
- Detect: Monitor the AWS Service Health Dashboard and correlate with your CloudWatch metrics.
- Calculate: Determine the affected services and the actual uptime percentage for the billing period.
- File: Open a case in AWS Support Center. Select “Account and Billing” → “Service Credit Request.”
- Provide: Include the affected service, region, time period, calculated uptime percentage, and any supporting evidence.
- Wait: AWS reviews the claim and either issues the credit or responds with their own calculation.
- Deadline: Must be filed before the end of the second billing cycle after the incident.
Azure Claim Process
- Detect: Monitor Azure Service Health and correlate with your Azure Monitor data.
- Calculate: Determine actual uptime for each affected service against the published SLA.
- File: Submit a support request through the Azure portal. Navigate to Help + Support → New Support Request → Billing.
- Provide: Include the service name, region, time period, your calculated downtime, and evidence from Azure Monitor.
- Wait: Microsoft reviews and processes the credit.
- Deadline: Must be submitted within 2 months of the end of the billing month in which the incident occurred.
GCP Claim Process
- Detect: Monitor the Google Cloud Status Dashboard and correlate with Cloud Monitoring.
- Calculate: Determine the monthly uptime percentage for affected services.
- File: Create a support case through the Google Cloud Console.
- Provide: Describe the SLA breach, include the affected project, service, time period, and evidence.
- Wait: Google reviews and applies the credit.
- Deadline: Must be filed within 30 days of becoming eligible. This is the tightest deadline — miss it and the credit is gone.
Why Manual Claiming Doesn’t Scale
The manual process works for a single major incident on a single cloud. It doesn’t work for ongoing monitoring across multiple services, multiple regions, and multiple clouds.
Consider what continuous monitoring requires:
- Polling service health APIs across all three providers, continuously
- Correlating service health events with your specific resource deployment
- Calculating actual uptime against SLA thresholds for each service tier
- Tracking claim deadlines that differ by provider
- Assembling evidence packages with timestamps, metrics, and impact analysis
- Filing claims in three different support portals with three different formats
- Tracking claim status until credits are issued
This is a full-time job. For most companies, the cost of doing it manually exceeds the credits recovered. Which is exactly why the providers can count on you not claiming.
What We Built to Solve This
This is why we built the SLA Recovery Engine inside Fintropy.
The engine continuously monitors SLA commitments across AWS, Azure, and GCP — 24/7, across every service you run. When a provider’s service health degrades, Fintropy:
- Detects the breach by correlating provider service health data with your specific resource deployments
- Calculates whether the degradation crosses the SLA threshold for your service tier
- Collects evidence — timestamps, affected resources, duration, calculated uptime percentage
- Auto-creates the refund case with the appropriate provider, including all required evidence
- Tracks the credit until it lands in your account
No manual monitoring. No missed deadlines. No evidence gathering. The credits that were always owed to you actually arrive.
What You Should Do Right Now
Even without any tool, you can start by doing three things today:
First, look up the SLA page for your primary cloud provider. Read the actual uptime commitments for the services you use. Most people are surprised by what’s promised.
Second, check the provider’s service health history for the last 12 months. Count the incidents that affected the regions where you run workloads. Compare the duration against the SLA thresholds.
Third, calculate a rough estimate of unclaimed credits. Even a ballpark number will be eye-opening — and it’s the number that gets a CFO’s attention.
If the number is significant enough to justify action, you have two choices: build an internal process to monitor and claim going forward, or use a tool like Fintropy that automates the entire flow.
Either way, stop leaving money on the table. It’s already yours. You just need to ask for it.
Fintropy is currently in closed beta with 470+ cost optimization rules and automated SLA credit recovery across AWS, Azure, and GCP. Learn more at nuvikatech.com/Fintropy_Overview.html