An Azure service that provides a hybrid, multi-cloud management platform for APIs.
If you are using non-streaming requests then this might be the reason. POST /openai/v1/responses calls with stream=false might experience a latency spike before completing or timing out.
To bypass the timeout, try changing your code logic from buffered (non-streaming) to streaming responses. If you are using the OpenAI SDK or a direct HTTP client, toggle the stream flag:
# Change this:stream=False# To this:stream=True
Switching to stream=True forces Microsoft Foundry to process the response chunk by chunk, bypassing the internal backend buffering delay and returning the fully drained response in under a second.
If you are running on a shared Global Standard SKU, this latency may be not necessarily be a typical noisy-neighbor or quota-throttling (429) issue.
To investigate further, verify your gateway logs or response headers. If you see an openai-processing-ms or platform delay metric on the responses path but not on chat/completions, this may indicate that you are encountering the platform issue. If your processes are failing entirely, ensure your HTTP clients do not have a hard-coded timeout lower than the time the stalled endpoint takes to complete. Also, check Azure Service Health in the portal for localized incidents in your active deployment region.
If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
hth
Marcin