Microsoft
Azure OpenAI SLA and support. Uptime is not the whole story.
The 99.9 covers availability only. Latency, retirement risk, and support severity are bought separately, and they negotiate.
The 99.9 covers availability only. Latency, retirement risk, and support severity are bought separately, and they negotiate.
Azure OpenAI carries a 99.9 percent availability SLA that pays 10 or 25 percent of one month of one service, and Azure gives you two months after the end of the billing month to claim it. There is also a latency SLA, published as a per-model floor on token rate rather than a response time, that almost nobody quotes back. Both numbers are smaller than they sound, and both can be drafted around.
The Azure OpenAI service carries a 99.9 percent availability SLA, and that number answers exactly one question: did the endpoint return a response. The online services SLA terms define the metric, the credit ladder, and the claim mechanics. Microsoft also carries a separate 99 percent latency SLA for token generation, announced alongside Data Zones in November 2024, which is a far smaller promise than the name implies.
Time to first token, sustained throughput under burst, and model output quality sit outside both commitments. For a production AI feature those are the failure modes that actually reach an executive, and the availability number is the one every contract review spends its afternoon on.
What the SLA covers versus what production needs
| Risk | In the SLA? | Where protection actually comes from |
|---|---|---|
| Service unavailable | Yes, 99.9 percent | Credit claim after breach |
| Slow responses, latency spikes | Partly; provisioned only | The published Latency Target, plus a drafted response time clause |
| Throttling at high load | No | PTU reservation sizing |
| Model quality regression | No | Deployment pinning and eval gates |
| Model retirement | No | Migration planning, contract notice terms |
Ten percent, or twenty five percent, of what you paid for the affected service in that month. Not the Azure bill, not the agreement, and never in cash. The ladder is short, it is printed in the SLA for Microsoft Online Services, and most people arguing about the 99.9 have never read it.
| Monthly Uptime Percentage | Downtime that gets you there in a 30-day month | Service credit |
|---|---|---|
| Below 99.9 percent | More than 43.2 minutes | 10 percent |
| Below 99 percent | More than 7 hours 12 minutes | 25 percent |
A 30-day month is 43,200 minutes. One tenth of one percent of that is 43.2 minutes; one percent is 432 minutes, or 7 hours 12 minutes. In a 31-day month every threshold rises by about 3 percent, which is why an incident bridge should log minutes and not adjectives. Source: the Azure AI services credit table in the SLA for Microsoft Online Services. A few Azure services carry a further rung at 95 percent uptime that pays 100 percent of the monthly charge; the AI services table we read stops at 25 percent. That document is versioned by date on the Microsoft licensing site, so confirm the rung count in the version attached to your own agreement before anyone builds a case on a full refund.
Take one production deployment billing $180,000 a month. Substitute your own figure; the multipliers do not move.
Run the same outage for eight hours and it moves one rung. 480 divided by 43,200 is 1.11 percent down, 98.89 percent up, below 99 percent, so 25 percent, so $45,000. That is the top of Microsoft's financial exposure to your worst AI day on that bill: somewhere between $18,000 and $45,000 of discount on money you were going to spend anyway. Weigh that against what 95 minutes of a dead assistant costs the business before you decide how hard to fight for another nine.
The Claims section of the SLA for Microsoft Online Services sets two different deadlines, and enterprises that run one incident runbook across the whole Microsoft estate get one of them wrong. Azure claims must reach Microsoft within two months of the end of the billing month in which the incident occurred. Every other Microsoft online service must be claimed by the end of the calendar month following the incident. A February incident on Microsoft 365 is dead on April 1. The same February incident on Azure OpenAI still has April.
The Claims section also names the four things the claim must carry: a detailed description of the incident, the time and duration of the downtime, the number and location of affected users, and a description of your attempts to resolve the incident at the time it happened. The fourth item is what kills retrospective claims. If nobody opened a support case while the service was down, there is no record of an attempt to resolve, and the claim fails on paperwork rather than on facts. Open the case during the outage even when you already know it is Microsoft's problem.
Provisioned throughput is the latency instrument. Provisioned throughput units reserve model processing capacity with consistent latency, where standard pay as you go shares capacity and absorbs the noisy neighbor problem.
Above 60 percent sustained utilization before adding capacity. The 35 to 55 percent utilization we found in our reviews means a third to half of reserved AI capacity was paid headroom.
There is a latency SLA. Microsoft announced a 99 percent latency service level agreement for token generation in November 2024, in the same post as Data Zones, and the numbers behind it sit in a column headed Latency Target in the table called Deployment parameters and throughput values by model, on the provisioned throughput sizing page. Almost nobody quotes it back across the table, which is a waste, because it is the only performance commitment Microsoft has already put in writing.
Three things shrink it. It is a floor on output token rate, not a response time. It is measured as p50 request latency on a per five-minute basis, so a bad five minutes inside a good hour vanishes. And it lives on provisioned deployments; on Standard, the metrics that would evidence it are not emitted at all.
| Model | Published Latency Target | Input TPM per PTU | Minimum PTU, Global or Data Zone | Minimum PTU, Regional |
|---|---|---|---|---|
| gpt-4o | 99 percent above 25 tokens per second | 2,500 | 15 | 50 |
| gpt-5 | 99 percent above 50 tokens per second | 4,750 | 15 | 50 |
| gpt-5-mini | 99 percent above 80 tokens per second | 23,750 | 15 | 25 |
| gpt-5.5 | 99 percent above 100 tokens per second | 1,200 | 15 | 50 |
Source: Deployment parameters and throughput values by model, Microsoft Foundry provisioned throughput sizing documentation, read July 2026. Targets are measured as p50 request latency on a per five-minute basis. Global and Data Zone deployments scale in increments of 5 PTU. Regional deployments scale in increments of 50 PTU for gpt-4o, gpt-5 and gpt-5.5, and 25 PTU for gpt-5-mini.
A target is a floor, not a speed. Take a 600-token answer, which is a short paragraph plus a bullet list.
Microsoft can deliver exactly that, month after month, and sit comfortably inside its own published target, because the target is a floor on token rate and the availability SLA counts responses rather than seconds. If a product owner has promised the business a two-second answer, the distance between that promise and the vendor's own published floor is a number the architects should see before the reservation is signed, not after the first executive complaint.
All four live under Microsoft.CognitiveServices/accounts in Azure Monitor. AzureOpenAITimeToResponse is Time to Response. AzureOpenAINormalizedTTFTInMS is Normalized Time to First Byte, the closest thing to time to first token. AzureOpenAINormalizedTBTInMS is Time Between Tokens. AzureOpenAITTLTInMS is Time to Last Byte. Microsoft's own monitoring guidance tells you to use these rather than the legacy Latency metric in the HTTP Requests category, and the legacy metric is what most enterprise dashboards are still charting. Two of them, plus Tokens Per Second, are not emitted for Standard deployments at all, so on pay as you go you cannot evidence a latency breach even if you win the clause.
The availability percentage will not move. A response time service level can, because Microsoft has already published the number and already calls it an SLA. What is missing is a remedy attached to it. Ask the account team to point at the credit ladder for the latency SLA; if nobody can, that gap is the clause. Language we have put in front of Microsoft, for the reader to hand to legal:
Model Response Time Service Level. For each Provisioned deployment listed in Exhibit A, Microsoft will maintain, in each billing month, a Token Rate Percentage of not less than 99 percent, where Token Rate Percentage is the proportion of five-minute intervals in which the p50 output rate for that deployment, measured by the AzureOpenAITokenPerSecond metric in Azure Monitor, equals or exceeds the Latency Target published for the deployed model in the Deployment parameters and throughput values by model table as of the Effective Date. Intervals containing fewer than fifty requests are excluded. The parties will additionally agree a P95 value on AzureOpenAINormalizedTTFTInMS for each such deployment, measured at one-minute grain. Failure to meet either level in a billing month entitles Customer to a service credit of ten percent of the Provisioned charges for the affected deployment, claimed under the Claims section of the SLA for Microsoft Online Services.
Two drafting points decide whether that clause survives contact. Pin the table to the Effective Date, because the published targets move when the model line-up moves, and an unpinned reference lets a retirement reset your service level downward with your signature already on it. And check you can measure it before you argue about it: the latency-sensitive path has to sit on provisioned capacity for the metrics to exist at all.
Size from measured tokens per minute against the published input TPM per PTU, and measure with AzureOpenAIProvisionedManagedUtilizationV2 rather than a forecast. Take a measured peak of 150,000 input tokens per minute on gpt-4o.
Model choice does the same thing in the other direction. That 150,000 tokens per minute needs 31.6 PTU on gpt-5 at 4,750 input TPM per PTU, which rounds up to 35 on a 5 PTU increment. On gpt-5.5, at 1,200 input TPM per PTU, the same traffic needs 125. Same workload, same region, roughly 3.6 times the capacity purchase, for what reads on a release note like a version bump. Rerun this arithmetic before every model migration, because the migration itself is the price change.
The SLA is not support. Severity response times, escalation paths, and engineering access come from your Azure support plan, purchased separately or wrapped into a Unified agreement.
| Azure support plan | List price per month | Sev A, critical | Sev B, moderate | Sev C, minimal |
|---|---|---|---|---|
| Basic | Included | No technical support | No technical support | No technical support |
| Developer | $29 | Not covered | Not covered | 8 business hours |
| Standard | $100 | 1 hour | 4 hours | 8 business hours |
| Professional Direct | $1,000 | 1 hour | 2 hours | 4 business hours |
| Microsoft Unified | Not published | 1 hour, 15 minutes at the top severity | 2 hours | 4 business hours |
Source: Azure support plans page, list price, read July 2026. Prices are per month. Azure support plan prices are published; Unified is not.
Read that table against what actually happens to an AI workload. A model that has stopped answering is a Sev A, and Standard at $100 a month already gives you a one-hour response on it. The incident you will really file is degraded latency on a service that is still returning 200s, and that is a Sev B. Standard answers a Sev B in four hours. Professional Direct answers it in two. The $900 a month between them, $10,800 a year, buys exactly one thing: half the wait on the only severity your AI incidents are ever going to qualify for. That is the whole decision, and it is usually made by someone who never read the severity table.
Microsoft does not publish Unified rates. The model is a percentage of your annual Microsoft spend by category, not a fee for the support you consume, which is the single most important sentence in any Unified renewal. The bands widely cited in the market, and consistent with what we see in Unified renewals, are roughly 8 to 10 percent of online services spend, which includes Azure consumption, and around 25 percent of on-premises license and Software Assurance spend, with Advanced running 30 to 45 percent above Core and Performance 60 to 90 percent above Core. Treat all of those as observed bands, not published rates.
Now push the AI line through it. A deployment billing $180,000 a month is $2,160,000 a year of Azure consumption. At 8 to 10 percent, that one workload adds roughly $172,800 to $216,000 a year to a Unified bill before anyone has opened a case. Professional Direct, with its two-hour Sev B, is $12,000 a year flat and does not care how big the AI estate gets. When the AI line is the thing growing fastest, the arithmetic for pricing Azure separately against Professional Direct is worth putting on paper before the support renewal, not after it.
No. Azure OpenAI is an Azure service under Azure support terms. A Microsoft 365 support relationship does not carry severity commitments for your Azure AI deployment.
The SLA itself rarely moves, but the commercial frame around it does. In our 2024 to 2025 reviews, PTU reservation pricing, term flexibility, and migration support moved 15 to 25 percent of committed AI spend.
Yes. Azure OpenAI consumption draws down a Microsoft Azure Consumption Commitment like any Azure service, which makes the AI line part of your negotiated discount fabric instead of a side purchase.
Most SLA reviews arrive on our desk with red ink on the availability percentage and an instruction to push Microsoft toward another nine. It buys nothing. Across the 12 to 18 Azure OpenAI commitment reviews in our 2024 to 2025 file, not one incident that caused measurable business damage was an availability breach. They were latency collapses on a service that kept answering, and no percentage on the availability line reaches those at all. An extra nine costs Microsoft very little to concede and pays a credit on an outage you will probably never have. Put the capital somewhere it lands: a credit remedy attached to the published Latency Target, that target pinned to the Effective Date, the Sev B response number rather than the Sev A one, and retirement notice. A nine never paid for a slow checkout.
Three cuts of our advisory engagement file frame the size of the opportunity.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Seven moves turn this analysis into a lower invoice and a shorter argument on the next incident.
White Paper · Microsoft
Azure OpenAI Service Commitment Playbook
When Azure OpenAI PTUs beat Pay As You Go and when they do not, plus the model price drops and regional capacity traps that change the commit math. Read it free.
A 99.9 percent availability SLA, with service credits as the only remedy. It measures whether the service returned a response, not how fast it returned it or how good the answer was, so latency and quality risk need separate instruments.
Ten percent of the affected service charge for that month if monthly uptime falls below 99.9 percent, and 25 percent if it falls below 99 percent. In a 30-day month those thresholds are 43.2 minutes and 7 hours 12 minutes of downtime. On a $180,000 monthly bill, a 95-minute outage is an $18,000 credit and an eight-hour outage is $45,000.
The Claims section of the SLA for Microsoft Online Services gives Azure claims until two months after the end of the billing month in which the incident occurred. Non-Azure Microsoft services get only until the end of the following calendar month. The claim must carry a description of the incident, its time and duration, the number and location of affected users, and what you did to resolve it while it was happening.
The 99.9 percent availability SLA does not; it counts responses, not seconds. There is a separate 99 percent latency SLA for token generation, announced in November 2024, expressed as a per-model floor on output token rate and applying to provisioned deployments. Ask Microsoft to point at the credit ladder attached to it before you rely on it.
Yes. The Latency Target column in the Deployment parameters and throughput values by model table lists a floor for each model: 99 percent above 25 tokens per second for gpt-4o, 50 for gpt-5, 80 for gpt-5-mini and 100 for gpt-5.5, measured as p50 request latency on a five-minute basis. At the gpt-4o floor a 600-token answer takes 24 seconds and Microsoft is still inside its target.
List price is $29 a month for Developer, $100 for Standard and $1,000 for Professional Direct. Standard and Professional Direct both answer a Sev A in one hour. The difference is Sev B, four hours against two, and Sev B is the severity a latency incident actually gets. Unified pricing is not published and is charged as a percentage of Microsoft spend.
Yes. Monthly and yearly PTU reservations discount steeply against hourly rates, and reservation pricing moved 15 to 25 percent in commitment reviews we advised in 2024 to 2025 when tied to broader Azure growth.
Yes. Azure OpenAI consumption draws down a Microsoft Azure Consumption Commitment like any Azure service, so route the AI line through the MACC to earn your negotiated discount structure.
Deployments on retired versions are forced to migrate on Microsoft's lifecycle schedule, and the SLA pays nothing for the migration work. Negotiate notice periods and migration assistance into the agreement before committing.
PTU sizing math, reservation benchmarks, and the contract terms that matter more than the SLA.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
The SLA tells you when Microsoft owes you an apology. The PTU reservation tells you when your customers get an answer. Fund the second.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Pricing moves, audit signals, and the levers that work. No vendor spin.
