How to Track Azure OpenAI Quota Across Sprint Teams

Three squads share one Azure subscription. Squad A runs a load test on Tuesday, and squad B's demo returns 429s on Wednesday. By the end of this guide you will know how to read your Azure OpenAI quota, give each team its own deployment slice, and get an alert before a demo breaks.

The key fact from the Azure OpenAI quota docs: quota is assigned per subscription, per region, per model and deployment type, in tokens per minute (TPM). You then carve that pool into deployments. Nothing splits it per team for you, so you have to do it.

Check your Azure OpenAI quota and what is left

Start with what the subscription has in a region:

az login
az account set --subscription <your-subscription-id>
az cognitiveservices usage list --location <region> -o table

This lists quota names with current usage and limit. Quota is also visible in the Azure AI Foundry portal under the Quota page. Look for the row that matches your model and deployment type, such as a GlobalStandard row for your model. Usage is what existing deployments have already claimed, not what they are actually consuming.

Split Azure OpenAI deployment quota per team

Create one deployment per team, named after the team, each with an explicit capacity. For standard deployment types one capacity unit is 1,000 TPM.

for team in checkout search support; do
  az cognitiveservices account deployment create \
    --name <your-openai-resource> \
    --resource-group <your-rg> \
    --deployment-name "${team}-chat" \
    --model-name <model-name> \
    --model-version "<model-version>" \
    --model-format OpenAI \
    --sku-name GlobalStandard \
    --sku-capacity 50
done

Each deployment above claims 50K TPM. Pick a model name and version that your region actually offers, and check the Models page first. Keep a buffer of unassigned quota for the team that has a demo this week, and for experiments.

Teams that need hard isolation can get their own resource in their own resource group. The pool is still shared underneath, but access keys, RBAC and metrics stay separate.

Make each team's 429s visible in code

Responses carry rate-limit headers. Log them so a team sees its headroom before it hits zero.

import os
from openai import AzureOpenAI

client = AzureOpenAI(
    azure_endpoint=os.environ["AZURE_OPENAI_ENDPOINT"],
    api_key=os.environ["AZURE_OPENAI_API_KEY"],
    api_version="2024-10-21",
    max_retries=3,
)

raw = client.chat.completions.with_raw_response.create(
    model="checkout-chat",  # your deployment name, not the model name
    messages=[{"role": "user", "content": "ping"}],
    max_tokens=5,
)
print(raw.headers.get("x-ratelimit-remaining-tokens"))
print(raw.headers.get("x-ratelimit-remaining-requests"))
completion = raw.parse()

The SDK retries 429s with backoff by default, which hides pain. Logging the remaining-tokens header tells you how close you ran to the ceiling.

Alert on Azure OpenAI tokens per minute before the demo

Azure Monitor exposes token metrics on the resource. Create an alert that fires when prompt tokens in a window approach the deployment's TPM.

az monitor metrics alert create \
  --name "checkout-tpm-80pct" \
  --resource-group <your-rg> \
  --scopes $(az cognitiveservices account show -n <your-openai-resource> -g <your-rg> --query id -o tsv) \
  --condition "total ProcessedPromptTokens > 40000" \
  --window-size 1m \
  --evaluation-frequency 1m \
  --action <your-action-group-id> \
  --description "Checkout deployment near 50K TPM"

The threshold is 80% of the 50K example. Add a dimension filter on ModelDeploymentName in the portal alert builder so each team's alert watches only its own deployment. Confirm the dimension names there, since the portal lists what your resource supports.

Review quota in sprint ceremonies

Put a ten-minute quota check into sprint planning. Each team states its expected load for the sprint, you compare it with the usage output, and you move capacity by updating the deployment's --sku-capacity. Capacity changes apply to the deployment, so do them before the demo, not during it.

Gotchas

• Assigned quota is not consumption. An idle deployment still holds its TPM until you lower it.
• Quota is per region. A team in another region draws from a separate pool.
• Requests per minute are tied to TPM, so many tiny calls can throttle you before tokens do.
• Raising the pool itself means a quota increase request through the Foundry portal. Don't plan a demo around its approval time.
• Large max_tokens values count against your rate estimate even if the answer is short.

One deployment per team plus one alert per deployment turns surprise 429s into a line item in sprint planning, which is exactly where production AI problems are cheapest to fix.