Azure OpenAI gpt-5-mini deployment returns HTTP 403 "unusual behavior — temporarily blocked" — how to unblock + prevent recurrence?

Parag Srivastava 25 Reputation points
2026-05-21T17:52:34.05+00:00

Details (paste into the Details textarea)

## Summary

My Azure OpenAI resource `bda-ai-foundry` is returning HTTP 403 with the error message:

> "Your resource has been temporarily blocked because we detected unusual behavior."

This occurs on 

I need help with:
1.
2.
3.

---

## Resource details

-
-
-
-
-
-
-

---

## Reproduction

Minimal probe (returns 403 every time, in ~0.9 seconds):

```bash
curl -X POST \
  "https://bda-ai-foundry.openai.azure.com/openai/deployments/gpt-5-mini/chat/completions?api-version=2024-12-01-preview" \
  -H "api-key: <KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role":"user","content":"hi"}],
    "max_completion_tokens": 10
  }'

Response:

{
  "error": {
    "code": "Forbidden",
    "message": "Your resource has been temporarily blocked because we detected unusual behavior."
  }
}

The same error occurs on:

  • The gpt-5-mini deployment via /openai/deployments/.../chat/completions
  • Other deployments on the same resource (gpt-5-pro via /openai/responses, etc.)

What my workload actually looks like

This is a charitable / educational non-profit (Bharat Dharma Academy, bda.ai) using the Elevate grant. The workload is:

  • One background worker (temple_ai_enricher.py) running on a Mac, enriching ~530 temple records per day = roughly 0.4 requests per minute sustained, well under any documented rate limit.
  • One web service on Render (a panchang/Jyotish calendar chat) — light interactive traffic, typically < 1 request per minute.
  • The same API key is used from both locations (Render in Virginia + Mac in Sydney).

I have a client-side rate limiter and circuit breaker (engine/ai_rate_limiter.py) configured to:

  • DeepSeek Foundry: 45s minimum interval (= 1.3 RPM)
  • Llama Foundry: 45s
  • gpt-5-mini: 60s minimum interval (= 1 RPM)
  • gpt-5-pro: 120s minimum interval (= 0.5 RPM)
  • Auto-open circuit on 403/429/"unusual behavior" for ≥ 1 hour

So the sustained rate Microsoft should be seeing is well under 2 RPM cumulative, with no documented burst in the affected period.

What I think may have triggered it (best guesses — would appreciate confirmation)

  1. Geographic spread of the same API key — same key used from Render (Virginia, US) and from my workstation (Sydney, Australia) in the same minute. Could this trigger an anomaly signal?
  2. Demo / smoke-test scripts (Kamakshi temple enrichment quality demos) executed by hand — these bypass my rate limiter and could have done 5–10 rapid calls.
  3. Pattern after long quiet — sudden 5–10 calls after several hours of zero traffic.

Questions for support

  1. Can you manually clear the block on bda-ai-foundry for the gpt-5-mini deployment? It has not auto-cleared in 24+ hours.
  2. Can you tell me what specifically triggered the anomaly detector? (Approximate timestamp, IP, deployment, request type would help me fix the root cause.)
  3. What is the actual rate-limit / pattern threshold for "unusual behavior" detection on Azure OpenAI? I cannot find this documented — the published TPM/RPM limits are far higher than what I am sending.
  4. Best practice for sharing one API key across two regions (Render US + my Mac in Australia). Should I:
    • Create separate deployments / separate keys for each consumer? or
      • Restrict by IP / managed identity?
      1. Is there a way to whitelist my IPs / set a "trusted workload" tag so the anomaly detector tolerates my pattern? The Elevate grant page says this resource is intended for production.

What I've already tried

  • Waited 24+ hours — block has not auto-cleared.
  • Confirmed key + endpoint + api-version are correct (same combo worked on 2026-05-19 / 2026-05-20, see Architecture.md §22.115 for the smoke-tested deployments).
  • Stopped all client workers, set local circuit breaker flag to refuse all calls to this resource until cleared.
  • Single curl probe with max_completion_tokens: 10 still returns 403 in 0.9s — so it is not a quota / token issue, the block is at the front door.
  • All known callers are now rate-limited; paid OpenAI direct fallback is also disabled in my pipeline.

Happy to provide:

  • Full request headers / response headers from the failing probe
  • Application Insights / Log Analytics traces if you point me to the right query
  • Resource ID, deployment ID, tenant ID via private channel

Thank you — this is blocking a live charitable project that the Elevate grant was specifically intended to support.

---
## Tag suggestions (paste into Tag field after clicking "Generate tags")
If the auto-generator doesn't pick the right ones, manually add:
- `azure-openai`
- `azure-ai-foundry`
- `gpt-5-mini`
- `azure-ai-services`
- `quota-and-limits`
---
## A few tips before you post
1. **Fill in the region** in the Resource details section (line: `Region: *(please fill in — e.g. East US 2)*`). You can find it in the Azure Portal → bda-ai-foundry → Overview.
2. **Do NOT paste your API key** anywhere in the public Q&A post. Where I wrote `<KEY>` in the curl example, leave it as `<KEY>` — Microsoft engineers will look up the resource by subscription ID + resource name, not by key.
3. **Do NOT paste the actual subscription ID** if you want to keep it private — you can replace it with "I'll provide via private channel" and Microsoft support will route accordingly. But since subscription IDs alone are not secrets (they're just identifiers, not credentials), most people do post them.
4. **If you have an Azure support plan** (any tier above "Basic"), opening a **support ticket from the Azure Portal** is *much* faster than Microsoft Q&A — usually 24-hour first response vs Q&A's "best effort." Q&A is community + occasional Microsoft engineer. For a billing/grant-related production block, the support ticket route is better.
### My recommendation: open a support case, not Q&A
For "my resource is blocked and I have a grant," the right path is:
**Azure Portal → Help + Support → New Support Request →**
- Issue type: **Technical**
- Service: **Azure OpenAI**
- Resource: `bda-ai-foundry`
- Problem type: **Connectivity, Latency, or Performance issues**
- Problem subtype: **My request is being throttled**
- Severity: **B** (Moderate impact — blocks production but you have workarounds)
Then paste the same content as the description. Microsoft support guarantees first response within hours for grant-funded resources. Q&A could sit for days.
Want me to draft the Azure Portal support-ticket version too (it has slightly different field structure)?
Azure AI Anomaly Detector
Azure AI Anomaly Detector

An Azure service that identifies anomalies and defects early with time-series detection.

Answer accepted by question author
Jerald Felix 18,760 Reputation points Volunteer Moderator
2026-05-22T08:59:00.0066667+00:00

Hello Parag Srivastava ,

Greetings! Thanks for raising this question in Q&A forum.

The HTTP 403 "unusual behavior — temporarily blocked" error from Azure OpenAI is triggered by Azure's anomaly detection system, which monitors usage patterns rather than just raw rate limits. Even if your requests per minute are well within published limits, the system can flag your resource when it sees traffic coming from multiple geographically distant locations using the same API key (Virginia + Sydney in your case), combined with sudden bursts after long periods of silence. This is a security signal, not a quota issue — which is why the block does not auto-clear and why even a minimal curl probe with max_completion_tokens: 10 hits the wall immediately.

Here are the steps to get unblocked and prevent this from happening again:

Step 1: Open an Azure Support Ticket immediately (most important)

Since the block has not auto-cleared in 24+ hours and this is a live grant-funded charitable project, Q&A alone will not unblock your resource. You need to raise a formal support ticket:

Go to Azure Portal → Help + Support → New Support Request and fill in:

  • Issue type: Technical
  • Service: Azure OpenAI
  • Resource: bda-ai-foundry
  • Problem type: Connectivity, Latency, or Performance
  • Problem subtype: My request is being throttled or blocked
  • Severity: B (Moderate)

In the description, mention your Elevate grant, the charitable nature of the workload, the low RPM (<2 RPM cumulative), and request manual clearance of the block along with the specific trigger reason.

Step 2: Use separate API keys for each calling location

Using a single API key from two geographically distant locations (US + Australia) is very likely what triggered the anomaly detector. Fix this going forward by:

  • Creating a dedicated API key for your Render worker (Virginia)
  • Using a separate API key for your Mac workstation (Sydney)

You can manage keys under Azure Portal → Your OpenAI Resource → Keys and Endpoint.

Step 3: Avoid burst patterns after long idle periods

Your smoke-test scripts that bypass the rate limiter and fire 5–10 rapid calls after hours of silence are a known trigger for anomaly detection systems. Going forward, add a warm-up delay in your test scripts — even a simple 5-second gap between calls during testing will help avoid this pattern looking like a sudden attack.

Step 4: Consider separate deployments per workload

Rather than routing both your background enricher and your web service through the same deployment, consider creating two separate deployments on the same resource — one for each workload. This gives Azure cleaner traffic signals per deployment and makes it easier to debug which workload triggered an issue.

Step 5: Enable Diagnostic Logs for future visibility

So you can investigate any future blocks yourself, enable logging now:

Go to Azure Portal → bda-ai-foundry → Diagnostic Settings → Add diagnostic setting, and route logs to a Log Analytics workspace. This will let you query request patterns and identify what triggered the anomaly detector next time.

Step 6: Reply to this thread with your Subscription ID (or provide via private channel)

If a Microsoft engineer picks up this Q&A post, sharing your subscription ID (it is not a secret credential) will allow them to look up the resource and verify the block status. You can also mention it is associated with the Elevate grant for prioritization.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards, Jerald Felix.Hello Parag Srivastava, Greetings! Thanks for raising this question in Q&A forum.

The HTTP 403 "unusual behavior — temporarily blocked" error from Azure OpenAI is triggered by Azure's anomaly detection system, which monitors usage patterns rather than just raw rate limits. Even if your requests per minute are well within published limits, the system can flag your resource when it sees traffic coming from multiple geographically distant locations using the same API key (Virginia + Sydney in your case), combined with sudden bursts after long periods of silence. This is a security signal, not a quota issue — which is why the block does not auto-clear and why even a minimal curl probe with max_completion_tokens: 10 hits the wall immediately.

Here are the steps to get unblocked and prevent this from happening again:

Step 1: Open an Azure Support Ticket immediately (most important)

Since the block has not auto-cleared in 24+ hours and this is a live grant-funded charitable project, Q&A alone will not unblock your resource. You need to raise a formal support ticket:

Go to Azure Portal → Help + Support → New Support Request and fill in:

  • Issue type: Technical
  • Service: Azure OpenAI
  • Resource: bda-ai-foundry
  • Problem type: Connectivity, Latency, or Performance
  • Problem subtype: My request is being throttled or blocked
  • Severity: B (Moderate)

In the description, mention your Elevate grant, the charitable nature of the workload, the low RPM (<2 RPM cumulative), and request manual clearance of the block along with the specific trigger reason.

Step 2: Use separate API keys for each calling location

Using a single API key from two geographically distant locations (US + Australia) is very likely what triggered the anomaly detector. Fix this going forward by:

  • Creating a dedicated API key for your Render worker (Virginia)
  • Using a separate API key for your Mac workstation (Sydney)

You can manage keys under Azure Portal → Your OpenAI Resource → Keys and Endpoint.

Step 3: Avoid burst patterns after long idle periods

Your smoke-test scripts that bypass the rate limiter and fire 5–10 rapid calls after hours of silence are a known trigger for anomaly detection systems. Going forward, add a warm-up delay in your test scripts — even a simple 5-second gap between calls during testing will help avoid this pattern looking like a sudden attack.

Step 4: Consider separate deployments per workload

Rather than routing both your background enricher and your web service through the same deployment, consider creating two separate deployments on the same resource — one for each workload. This gives Azure cleaner traffic signals per deployment and makes it easier to debug which workload triggered an issue.

Step 5: Enable Diagnostic Logs for future visibility

So you can investigate any future blocks yourself, enable logging now:

Go to Azure Portal → bda-ai-foundry → Diagnostic Settings → Add diagnostic setting, and route logs to a Log Analytics workspace. This will let you query request patterns and identify what triggered the anomaly detector next time.

Step 6: Reply to this thread with your Subscription ID (or provide via private channel)

If a Microsoft engineer picks up this Q&A post, sharing your subscription ID (it is not a secret credential) will allow them to look up the resource and verify the block status. You can also mention it is associated with the Elevate grant for prioritization.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

Was this answer helpful?

1 person found this answer helpful.
0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator
    2026-05-25T08:40:17.4333333+00:00

    Hi @Parag Srivastava

    Thank you for your patience. We received an update from the Product Group team and wanted to share the findings.

    The HTTP 403 error you are seeing with the message about unusual behavior is because your Azure OpenAI resource has been temporarily blocked by the platform’s abuse detection system. This is an intentional Trust and Safety action and not due to a service outage or platform bug.

    This kind of block can happen when the system detects patterns that look unusual, such as repeated requests, high frequency calls, or activity that may trigger safety or policy checks. From the platform side, this is expected behavior and is done to protect the service.

    At this stage, there is no configuration change or troubleshooting step that can unblock the resource directly from the service side. The correct way forward is to request a review through the abuse mitigation process.

    What you can do now is:

    • Submit an appeal through the Azure OpenAI abuse or mitigation request process
    • Provide your subscription details and resource name
    • Share a brief explanation of your usage scenario so the team can review and validate it

    Once submitted, the relevant team will review your case and take appropriate action if the block was applied in error.

    In short, this is not a technical issue in your setup but a safety enforcement action, and it requires review through the designated process.

    Please let me know if you need help.

    Thankyou!

    Was this answer helpful?

    0 comments
  2. Parag Srivastava 25 Reputation points
    2026-05-22T10:24:32.2633333+00:00

    Hello Jerald,

    Thank you for the detailed explanation. This makes sense, especially the point about the same Azure OpenAI key being

    used from geographically distant origins and occasional smoke-test bursts after idle periods.

    I am currently unable to create a formal Azure Support ticket. When I try to create one from the Azure Portal, I am

    repeatedly redirected back to this Q&A/support form, so I do not seem to have a path to submit the ticket directly.

    Could you please help escalate this to the Azure OpenAI support team or advise the correct path to open a ticket for

    this grant-funded resource?

    Subscription:

    Azure subscription 1

    f60e8dd3-ec1a-42bc-ba90-f79e7e835505

    Resource:

    bda-ai-foundry

    Issue:

    Azure OpenAI requests are returning HTTP 403 with “unusual behavior — temporarily blocked.” The block has persisted

    for more than 24 hours, and even minimal test requests fail immediately.

    Context:

    This is for Bharat Dharma Academy, a charitable / NFP Sanatan Dharma knowledge project using the Microsoft Elevate

    grant. Our normal usage is low, and we are implementing the mitigations you recommended:

    • separate API keys for Render/web and local/batch workloads
    • separate deployments per workload
    • serialized smoke tests with delays
    • diagnostic logging
    • rate limiting / circuit breaker on all Azure callers

    Could Microsoft please manually review and clear the block, and if possible share the specific trigger reason so we

    can prevent recurrence?

    Thank you,

    Parag Srivastava

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.