Only Some document is not added and gives 'RateLimitError'

Question

Only Some document is not added and gives 'RateLimitError'

Vimal Lalani 20

Hi Team,

I am facing an issue while uploading documents to Azure AI Search. Most documents are indexed successfully, but some seemingly similar documents fail with a RateLimitError. The failed documents appear to be random, and there doesn't seem to be any obvious difference between the documents that succeed and those that fail.

Issue Detail:

Using Azure AI Search to index documents.
Majority of documents are added successfully.
Some random documents fail with a RateLimitError.

Question:

What is the recommended approach to handle or prevent these errors?

Please avoid posting generic AI-generated responses. I have already tried many such suggestions without success. I'm looking for advice from people who have encountered this issue themselves or can provide guidance based on Azure AI Search documentation and practical experience.

Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-08T03:58:38.47+00:00

Hi @Vimal Lalani

Thank you for contacting us about the RateLimitError. issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-08T07:05:54.19+00:00
Hi @Vimal Lalani

Thank you for providing the detailed information. I understand that while the majority of your documents are being indexed successfully in Azure AI Search, a subset fails intermittently with a RateLimitError, and the failures appear random with no obvious differences between successful and failed documents.

This pattern is commonly associated with service throttling or transient processing limits rather than issues with the document content itself. Microsoft documentation notes that transient errors during indexing can affect only some documents in a given run due to temporary capacity constraints or downstream operations.

Recommended next steps:

Check the exact error details in the Indexer Execution History (or your application logs). This will clarify whether the 429 is coming from Azure AI Search or a downstream service (e.g., Azure OpenAI embeddings).

Implement retry logic with exponential backoff, honoring any Retry-After header. Scheduled indexer runs are also very effective at automatically reprocessing transiently failed documents.

Reduce batch size / concurrency if you're using the Push API or a custom ingestion process. Large bursts increase the chance of hitting throttling limits.

Monitor metrics in Azure Monitor for throttling events and consider scaling (adding partitions or moving to a higher tier) if this is frequent.

To help narrow this down quickly, could you share:

The full RateLimitError message (including any inner details or headers)

Whether you're using Indexers (pull model) or the Documents Push API (push model)

If Integrated Vectorization, Azure OpenAI Embeddings, or any Skillset is in use

Your Azure AI Search service tier and number of search units

Reference :

https://learn.microsoft.com/en-us/azure/search/cognitive-search-common-errors-warnings

https://learn.microsoft.com/en-us/azure/search/search-limits-quotas-capacity

https://learn.microsoft.com/en-us/azure/search/search-performance-analysis

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Vimal Lalani 20 Reputation points

2026-07-08T11:15:28.5466667+00:00
Thank you, Praneeth.

I appreciate the suggestions. However, I've already gone through the commonly recommended troubleshooting steps (retry logic, batch size adjustments, monitoring, scaling considerations, etc.), including similar AI-generated recommendations, without being able to resolve the issue.

I'm hoping to hear from someone who has personally encountered the same behavior or has been able to reproduce it in a similar setup and recommended approach to handle or prevent these errors

To answer your questions:

I'm using the Documents Push API from Databricks Python notebooks.

The Search service is on the Standard tier.

The 429/RateLimitError is occurring during embedding generation/indexing, but the behavior seems intermittent, with some similar documents succeeding while others fail.

If anyone has faced a similar issue with Azure AI Search and Azure OpenAI embeddings at scale, I'd be interested in learning what ultimately resolved it for you.
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-10T05:33:42.66+00:00
Hi @Vimal Lalani

Thank you for the additional details and for confirming that you've already tried the common mitigation steps.

Based on the behavior you've described, the intermittent 429/RateLimitError occurring during embedding generation may indicate throttling at the Azure OpenAI embedding deployment level, particularly when requests are processed in bursts. Microsoft documentation notes that rate limiting can occur due to Tokens Per Minute (TPM) or Requests Per Minute (RPM) limits and may appear intermittent even when similar documents are being processed

To better validate whether this is the underlying cause in your environment, could you please share:

The complete 429 error message, including any inner exception details

The embedding model being used (for example, text-embedding-3-small or text-embedding-3-large)

Whether embeddings are generated directly within the Databricks notebook before indexing, or through Azure AI Search integrated vectorization

Any Retry-After header or throttling details returned with the failed requests

These details will help determine whether the throttling originates from the Azure OpenAI embedding deployment or elsewhere in the indexing workflow and allow us to provide more targeted guidance.

Reference :

https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota?tabs=python

https://learn.microsoft.com/azure/search/cognitive-search-skill-azure-openai-embedding

I look forward to your update and will be happy to investigate further once we have the error details.

Answer accepted by question author

0 additional answers

Your answer

Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-08T03:58:38.47+00:00

Hi @Vimal Lalani

Thank you for contacting us about the RateLimitError. issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Vimal Lalani 20 Reputation points

2026-07-08T11:15:28.5466667+00:00

Thank you, Praneeth.

I appreciate the suggestions. However, I've already gone through the commonly recommended troubleshooting steps (retry logic, batch size adjustments, monitoring, scaling considerations, etc.), including similar AI-generated recommendations, without being able to resolve the issue.

I'm hoping to hear from someone who has personally encountered the same behavior or has been able to reproduce it in a similar setup and recommended approach to handle or prevent these errors

To answer your questions:

I'm using the Documents Push API from Databricks Python notebooks.

The Search service is on the Standard tier.

The 429/RateLimitError is occurring during embedding generation/indexing, but the behavior seems intermittent, with some similar documents succeeding while others fail.

If anyone has faced a similar issue with Azure AI Search and Azure OpenAI embeddings at scale, I'd be interested in learning what ultimately resolved it for you.
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-10T05:33:42.66+00:00

Hi @Vimal Lalani

Thank you for the additional details and for confirming that you've already tried the common mitigation steps.

Based on the behavior you've described, the intermittent 429/RateLimitError occurring during embedding generation may indicate throttling at the Azure OpenAI embedding deployment level, particularly when requests are processed in bursts. Microsoft documentation notes that rate limiting can occur due to Tokens Per Minute (TPM) or Requests Per Minute (RPM) limits and may appear intermittent even when similar documents are being processed

To better validate whether this is the underlying cause in your environment, could you please share:

The complete 429 error message, including any inner exception details

The embedding model being used (for example, text-embedding-3-small or text-embedding-3-large)

Whether embeddings are generated directly within the Databricks notebook before indexing, or through Azure AI Search integrated vectorization

Any Retry-After header or throttling details returned with the failed requests

These details will help determine whether the throttling originates from the Azure OpenAI embedding deployment or elsewhere in the indexing workflow and allow us to provide more targeted guidance.

Reference :

https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota?tabs=python

https://learn.microsoft.com/azure/search/cognitive-search-skill-azure-openai-embedding

I look forward to your update and will be happy to investigate further once we have the error details.

Answer 1

Because embeddings are generated in the Databricks notebook before the Documents Push call, this is most likely Azure OpenAI deployment throttling—not an Azure AI Search indexing limit. A Standard Search tier will not remove that 429.

The useful change is a single, deployment-wide rate limiter shared by all Databricks tasks. Do not let every partition retry independently. Queue embedding calls by deployment, cap in-flight calls, and when one call gets 429, pause the whole queue for the returned retry-after-ms period (plus jitter), then retry only the failed documents using their existing deterministic Search keys.

Similar documents can appear random because request rate is evaluated in short windows, not only as a per-minute total. Log x-ratelimit-limit/remaining-requests, x-ratelimit-limit/remaining-tokens, and retry-after-ms for each embedding call. That will show whether RPM or TPM is exhausted.

If those limits are routinely near zero, allocate more TPM or use a separate embedding deployment for bulk indexing so query traffic cannot contend with it. If the 429 says temporary capacity rather than rate limit, Search scaling will not help; reduce concurrency and retry after the supplied delay.