Load Balancer SLA Credits: The Healthy Backend Rule That Decides Your Claim
September 13, 2026
Load balancers carry some of the strongest uptime promises in cloud: 99.99% from AWS for any balancer spread across two or more availability zones, the same number from Google for load balancing on its premium network tier, and 99.99% from DigitalOcean on its global balancers. Then you reach the definition of down, and the promise narrows to one shape of failure. The balancer itself must be completely unreachable, measured in minutes, while at least one healthy backend still sits behind it. The incident that paged you at 2am rarely looks like that. The differences decide whether a claim exists at all.
The one requirement every load balancer SLA shares
Every provider measures load balancer uptime in minutes, and every definition of downtime requires a total loss of connectivity. AWS marks a balancer unavailable when it has no external connectivity and all attempts to connect to it fail. Azure marks a minute unavailable when all attempts to connect throughout the minute are unsuccessful. Google counts downtime as loss of external connectivity through the forwarding rules, caused by a failure of Google's systems. DigitalOcean asks for five or more consecutive minutes with no external connectivity, a floor that deletes short blips entirely.
The surprise: for AWS, Azure and Google, the failure only counts if something healthy is still behind the balancer. AWS requires at least one healthy target (a target that answers the health check). Azure requires the balancer to be serving two or more healthy VMs and counts downtime only when all of them lose connectivity through the load balanced endpoint. Google requires the loss to hit all healthy backend instances. If your fleet died and the balancer had nothing to route to, that is an incident, not an SLA event. Partial failures while other targets answered are not balancer downtime either. The contracts recognize one shape of failure: fully unreachable from outside, still healthy inside.
| Load balancer | Monthly commitment | Credit schedule |
|---|---|---|
| AWS ELB, multi-AZ | 99.99% | 10% below 99.99%; 30% below 99.0%; 100% below 95.0% |
| AWS ELB, single AZ or Gateway LB | 99.9% | 10% below 99.9%; 30% below 99.0%; 100% below 95.0% |
| Azure Standard Load Balancer | 99.99% | 10% below 99.99%; 25% below 99.9% |
| Azure Application Gateway | 99.95% | 10% below 99.95%; 25% below 99.0% |
| Azure Front Door | 99.99% | 10% below 99.99%; 25% below 99.9% |
| Google Cloud load balancing, premium tier | 99.99% | 10% below 99.99%; 25% below 99.0%; 100% below 95.0% |
| Google Cloud load balancing, standard tier | 99.9% | 10% below 99.9%; 25% below 99.0%; 100% below 95.0% |
| DigitalOcean Regional Load Balancer (size 2+) | 99.9% | 10% below 99.9%; 25% below 99.0%; 100% below 95.0% |
| DigitalOcean Global Load Balancer | 99.99% | 10% below 99.99%; 25% below 99.5%; 100% below 95.0% |
Microsoft's load balancing credits stop at 25%; Google's Mexico and Stockholm regions carry a lower 99.95% premium-tier commitment.
A load balancer only counts as down if something behind it is still up. The claimable event is total loss of connectivity, in whole minutes, with a healthy backend in place. If your outage did not match that shape, the credit was never on the table.
The preconditions that decide eligibility
Matching the failure shape is necessary, not sufficient. Each contract attaches conditions that plenty of deployments miss.
| Service | Covered at the headline commitment only if | Otherwise |
|---|---|---|
| AWS ELB | Spread across two or more AZs, with at least one healthy target | Single-AZ deployments fall to the 99.9% schedule; no healthy target means the clause never applies |
| Azure Load Balancer | Standard SKU serving two or more healthy VMs | Basic SKU has no SLA at all |
| Azure Application Gateway | Two or more medium or larger instances, or a deployment capable of autoscaling or zone redundancy | A single-instance gateway sits outside the clause |
| Azure Front Door | An independent measurement system you run: five or more locations, a test every five minutes, a 50KB object fetched through the service | Nothing to review means no basis for a claim |
| Google Cloud LB | Healthy backends, premium network tier for the 99.99% row | Standard tier drops to 99.9%; a partial loss of backends never registers |
| DigitalOcean | Regional balancer of size 2 or larger | Size 1 has no SLA |
Two entries deserve a second look. Azure excludes minutes lost to SNAT port exhaustion by name: when instances open more outbound flows than their allocated source ports can carry, connections fail in ways that look exactly like a balancer problem from your side, and none of those minutes count. And Front Door breaks from minute counting entirely: Microsoft reviews data from an independent measurement system the customer selects, with tests at least every five minutes from five or more geographically diverse locations against an object of at least 50KB, and uptime is the share of successful HTTP transactions.
The clocks and the claim itself
AWS does not let you stack claims: the Multi-AZ and Single SLAs cannot both be claimed for the same deployment, so pick the right one. The case needs "ELB SLA Credit Request" in the subject, the balancer's ARNs or DNS names, the billing cycle and region, and monitoring logs showing the failed connections, and it must reach AWS by the end of the second billing cycle after the incident. Google wants a support notification within 60 days of the moment you become eligible, with log files showing the downtime periods; the credit applies to the region's load balancing bill. Microsoft takes claims through a support request under your subscription; our Azure walkthrough covers that path.
DigitalOcean sets the strictest clock of the four: written notice within 24 hours of the downtime, or the credit is forfeited regardless of evidence. The claim itself then has until the end of the second billing cycle. AWS and DigitalOcean both ignore credits below $1.
What a load balancer credit is worth
Less than most teams expect. The credit is calculated on the balancer's own charges: AWS uses total charges for the applicable balancer in the breached month, DigitalOcean uses the affected resource's charges excluding one-time payments, and Google uses the monthly bill for load balancing in the region. Nothing behind the balancer is included. A 10% credit on a $22 monthly balancer is $2.20, which is why almost nobody files for a single one. The math gets real at fleet scale, where one organization can run hundreds of balancers and a bad month can push a dozen below commitment at once.
The evidence a claim needs
All four contracts ask for roughly the same file, and it has to exist before you need it:
- Connection or probe logs with timestamps in a stated time zone, captured from outside the failing path.
- The provider's own incident record: a status page entry, Service Health item or incident ID.
- Resource identifiers: ARNs or DNS names for AWS, subscription and resource group for Azure, project and region for Google, the specific resource for DigitalOcean.
- The billing cycle and region you are claiming against.
- For Front Door, the output of your independent measurement system.
The full evidence checklist is in what counts as evidence in an SLA credit claim.
One action: list every load balancer across your accounts and mark two facts next to each one. Which commitment row does it qualify for, and is anything you run measuring it from outside its own failure domain. The first tells you what a failure would be worth. The second decides whether you could prove it. Close the gaps before the next incident.