No SLA: IAM, Consoles, and the Parts of the Cloud That Never Pay Credits
September 18, 2026
When compute or storage fails, the cloud leaves a paper trail: a credit schedule, a claim window, a dollar figure. When the layers that let you sign in and manage everything else fail, there is usually nothing to claim at all. The biggest holes in the industry's SLA indexes sit where the engineering pain is worst: identity, the management consoles, organization management, and the health and billing pages. AWS will not pay you for an IAM outage. Google says so in writing. Microsoft pays for Entra ID lockouts but leaves the portal outside the promise. This post maps the coverage, and the exercise that finds your exposure.
What the indexes cover
The providers publish coverage in very different formats, and the gaps only appear when you read them side by side.
- AWS promises SLAs "for all paid, generally available services," and its index lists 179 of them. IAM is not one, and neither are Organizations, the Management Console, or the Health Dashboard. The only IAM-branded entry, Access Analyzer, covers its own API calls.
- Google's index points to about 110 service pages, and its IAM SLA page exists to say that none does. The console, Resource Manager, and Cloud Billing are absent as well.
- Microsoft folds everything into one document, more than 100 pages, covering Azure, Microsoft 365, Dynamics 365, and Intune. Entra ID sits inside with a full credit schedule. The portal appears only as the place where covered resources are listed. Resource Manager and Service Health get the same treatment.
- DigitalOcean keeps the shortest list: fourteen products, from Droplets to Spaces. The control panel is not one of them, and neither is team management.
| Layer | AWS | Microsoft | DigitalOcean | |
|---|---|---|---|---|
| Sign-in and permissions | Not in the index (Access Analyzer only) | Entra ID: covered, 10 to 100 percent | No SLA, stated in writing | Team management: not in the index |
| Management console | Not in the index | Not covered | Not in the index | Control panel: not in the index |
| Organization management | Organizations: not in the index | Not covered | Resource Manager: not in the index | Not in the index |
| Incident alerting | Health Dashboard: not in the index | Service Health: not covered | Status dashboard: not in the index | Uptime checks: not in the index |
The same split reaches billing: paid cost tools like AWS Budgets carry their own SLAs, while the billing pages you open to look at them are not covered anywhere.
The identity test
Identity is the sharpest test of how the three big indexes treat this layer, because every workload depends on it and they do not agree on whether an outage there is compensable.
AWS does not list IAM. The closest entry is Access Analyzer, which got its own SLA on June 16, 2025: 99.9 percent availability for a narrow set of APIs, with 10, 25, or 100 percent of what you spent on it as the payout. A login lockout, a failed role assumption, a broken key rotation: none of it has a document.
Google is blunter. Its IAM SLA page carries one sentence of substance, plus a pointer that services supporting IAM may carry their own promises.
No Service Level Agreement (SLA) applies to the Identity and Access Management (IAM) service.
One Google product does pay for identity failures. Cloud Identity Premium, a separate service, promises 99.9 percent availability and pays in days added to the term: 3, 7, or 15, with claims due within 30 days. Cloud IAM, the permission system guarding every project, has no uptime promise at all.
Microsoft is the outlier. Entra ID Basic and Premium are covered by the September 2026 consolidated SLA, and the definition of downtime is unusually human: any period when users cannot log in, or when the service fails to emit the tokens applications depend on. Downtime counts in user-minutes, each affected minute multiplied by the number of affected users. For 200 users, one bad hour is 12,000 user-minutes; as the month's only incident, that lands at 99.86 percent and inside the 25 percent credit band. Claims must reach Microsoft within 60 days of the incident.
| AWS | Microsoft | ||
|---|---|---|---|
| Identity service | IAM | Cloud IAM | Entra ID |
| Covered by an SLA | No (Access Analyzer only) | No, in writing | Yes, Basic and Premium |
| What pays | Access Analyzer: 10 to 100 percent of its own charges | Cloud Identity Premium: 3 to 15 days of service | 10 to 100 percent of Entra charges |
| Claim deadline | End of the second billing cycle | 30 days from eligibility | 60 days from the incident |
Why the gaps exist
None of this is sloppy drafting. Every credit in these documents is a percentage of what you paid for the failing service, and a service with no invoice line cannot produce a percentage of anything. AWS says as much by promising SLAs only for paid services, and IAM is offered at no additional charge. Google's IAM API is free of charge, and so are the consoles and organization management. Microsoft covers Entra because Entra has paid editions, and leaves the portal out because the portal is not a metered product.
The asymmetry inside AWS shows the rule cleanly. Access Analyzer has usage charges and an SLA; the service that authorizes every API call your account makes has neither. Google runs the same pattern a step apart: Cloud Identity Premium has a rate card and a credit schedule, Cloud IAM has a page telling you not to expect one. Leaving these services out is arguably honest, since a percentage of nothing is nothing. It just means the layers most likely to lock you out carry the least contractual protection.
What it means when these layers break
There is nothing to file for an uncovered layer, and hunting for a claim is wasted effort. The operational stakes are higher, because these are the tools you use to notice, diagnose, and respond to an incident. When identity or the console degrades, the question is not who pays. It is whether anyone can get back in.
The timing usually works out for everything else. Claim windows on covered services run from 30 to 60 days: AWS until the end of the second billing cycle, Azure 60 days, Google 30. An afternoon locked out of the console rarely costs you the claim on whatever started the mess, and control plane incidents rarely travel alone. An event that begins in a covered service often drags identity or the console along with it, which makes the whole thing feel uncompensable even when parts are directly claimable. Keep the lists separate, and file the covered half.
The exposure test
Run this once and your real availability picture falls out of it. Take the ten services your team depends on most and check each name against your provider's index: AWS on its legal pages, Google under its terms SLA index, Microsoft as a downloadable document, DigitalOcean on a single SLA page. Sort what you find into two columns: covered, and not covered.
Everything in the second column is engineering territory, because no document will ever pay for it. For each one, write a fallback line: what a three hour outage does to us, and who can get in when the normal path is gone. In practice that means one access route that survives the console, the identity plane, and the alerting tool failing together, credentials sealed outside the systems they open, and a test on a calendar, not a runbook.
Monitoring belongs on the same list. When the page that reports incidents has no uptime promise, the only record is the one you collect from outside, and that record is also what a claim needs.
One thing to do today
Open your provider's index and type in the name of every service in your architecture diagram, starting with identity, the console, and billing. Whatever is missing is engineering territory, not claims territory. Write the first fallback line for your top three gaps before the week ends. The credit system follows the meter. Your dependency graph does not. The distance between those two lists is your real availability plan.