The PaaS SLA Map: What App Service, App Engine, Beanstalk and App Platform Promise
September 20, 2026
Move from raw VMs to a managed platform and the uptime promise changes shape. Azure App Service carries a 99.95% commitment with service credits attached, and 99.99% for apps spread across availability zones. Google App Engine promises 99.95%, measured by error rate rather than connectivity, with a 50% ceiling on the payout. DigitalOcean's App Platform commits to 99.95% per component with a credit ladder that starts at 10% and reaches 100%. AWS Elastic Beanstalk has no SLA of its own: it does not appear in the AWS index of service level agreements, and no Beanstalk SLA page exists, which means the compensation trail runs down to the EC2, ELB and RDS resources underneath. Four platforms, four different answers to the same question: when the app goes down, who owes you?
What each platform actually promises
| Platform | Commitment | What counts as downtime | Claim window |
|---|---|---|---|
| Azure App Service | 99.95%, or 99.99% for apps across two or more availability zones | a minute with no connectivity between the app and Microsoft's Internet gateway | within two months of the end of the billing month |
| Google App Engine | 99.95% | an error rate above 10% for five consecutive minutes (serving infrastructure and the Search API) | 30 days from eligibility |
| AWS Elastic Beanstalk | none of its own | the underlying services' SLAs apply instead | per underlying service |
| DigitalOcean App Platform | 99.95% per app component | five or more consecutive minutes with no external connectivity, or a component that fails to start | end of the second billing cycle |
Two rows deserve a second look. App Service covers single-instance and multi-instance apps at the same 99.95% when availability zones are not in play, so the platform does not punish you for running one instance the way the VM SLA does. App Engine counts errors, not lost connectivity: a request that returns an INTERNAL_SERVING_ERROR, at an error rate above ten percent, sustained for five consecutive minutes, is what starts the clock. A network blip that your retries paper over earns nothing.
Elastic Beanstalk and the missing SLA
AWS commits to SLAs for the services listed in its index, and Elastic Beanstalk is not among them. Neither is App Runner. The reason for Beanstalk is simple: it costs nothing. You pay for the EC2 instances, load balancer, RDS databases and S3 buckets it provisions, and those services carry their own SLAs. They are the ones you claim under when an environment fails. It is worth stating plainly, because the mistake is common: there is no such thing as a Beanstalk credit request. If the environment's instances lose connectivity, that is an EC2 claim. If the load balancer stops routing, that is an ELB claim. AWS Support will help with Beanstalk issues, but support is not a service level agreement.
The name on the invoice decides who owes you. App Service and App Platform sell their uptime promises with the platform. App Engine sells one measured in error rates. Beanstalk bills nothing and promises nothing, so its compensation lives one layer down, in the EC2, ELB and RDS bills.
The credit ladders
| Platform | First tier | Middle tier | Top tier |
|---|---|---|---|
| App Service | 10% below the commitment | 25% below 99% | 100% below 95% |
| App Engine | 10% (99.0% to below 99.95%) | 25% (95% to below 99%) | 50% (below 95%) |
| App Platform | 10% (99.0% to below 99.95%) | 30% (95% to below 99%) | 100% (below 95%) |
| Beanstalk | no platform credit | no platform credit | no platform credit |
Three ladders, three shapes. Azure and DigitalOcean escalate to full credit once the month falls below 95%, roughly 36 hours of downtime. App Engine stops at 50%: Google caps the payout at half the bill and applies the credit within 60 days of the request. DigitalOcean's middle tier is the most generous of the three, 30% where Azure and Google pay 25%. The Beanstalk row is not an oversight: the platform layer has nothing to pay with, because it bills nothing.
Money math on a $500 platform bill
Thirty minutes of downtime in a 30-day month puts the uptime percentage at 99.931%.
| Scenario | App Service | App Engine | App Platform | Beanstalk |
|---|---|---|---|---|
| 30 minutes of downtime | $50 (10%) | $50 (10%) | $50 (10%) | $0; EC2, ELB and RDS claims run separately |
| 8 hours of downtime (98.889%) | $125 (25%) | $125 (25%) | $150 (30%) | $0; the underlying services answer |
Thirty minutes of platform trouble produces three near-identical cheques and one blank. The spread widens at scale: over eight hours, the middle tier separates Azure and Google at 25% from DigitalOcean at 30%. One more wrinkle for App Engine: if the errors never crossed ten percent for five straight minutes, the cheque is zero even if the app felt broken all afternoon.
The fine print worth knowing
- Azure credits apply only to fees for Web, Mobile, API and Logic apps, not to other app types sold through the App Service. App Service Environment v1 and v2 retired on 1 September 2024 and carry no service level guarantees at all.
- Google excludes alpha and beta features, and errors caused by quota limits. The covered service list is narrow: serving infrastructure plus the Search API, nothing else on the platform.
- DigitalOcean measures per app component, not per account, and pays only if the credit for the cycle exceeds one dollar. Standard exclusions cover customer code and configuration.
- On AWS, the practical equivalent of a platform guarantee is the set of SLAs on the resources a Beanstalk environment provisions. The health of the platform and the health of those resources are measured separately.
Filing, and the audit that matters
The routes are quick to write down. Azure takes a portal support request naming the incident, its duration and the affected resources, filed within two months of the billing month's end. Google wants a technical support contact with log files showing the downtime periods, inside 30 days from eligibility. DigitalOcean wants a support ticket naming the affected components, with dates, times and request logs, by the end of the second billing cycle. On Beanstalk, the route is whichever underlying service failed: the EC2, ELB, RDS or S3 channel, with that service's deadline.
The audit worth doing this week: open the cloud invoice and find the exact product name behind each application. If it is App Service or App Platform, the promise is attached to the platform, and the claim is straightforward. If it is App Engine, the record you need is an error-rate record, not a connectivity one. If it is Beanstalk or App Runner, write down the underlying services the environment provisions, because that list is your claim map. It is the same mapping work UptimeAudit does when it watches the big four's health feeds and drafts claims against what you actually run.