Origin response timeout configured at 240s but requests still timing out at 60s (OriginTimeout)

Question

I'm on the Developer support plan and have a Front Door Standard profile where originResponseTimeoutSeconds is confirmed set to 240 (via JSON view), but requests are consistently failing with OriginTimeout at almost exactly 60.0 seconds — the default timeout, not the configured value.

Setup:

• SKU: Standard_AzureFrontDoor
• Endpoint pattern: https://<my-endpoint>/api/v1/<my-route>
• Origin: confirmed healthy and responding directly (bypassing Front Door) in ~90-95 seconds for the same request

JSON view confirms the setting:

"properties": {

"originResponseTimeoutSeconds": 240,

"resourceState": "Active",

"provisioningState": "Succeeded"
```}  
  
KQL against FrontDoorAccessLog shows repeated failures at ~60s despite this:  
  
AzureDiagnostics

| where TimeGenerated > ago(6h)

| where Category == "FrontDoorAccessLog" and requestUri_s endswith "<my-route>"

| project TimeGenerated, requestUri_s, httpStatusCode_s, timeTaken_s, errorInfo_s

| order by TimeGenerated desc  
  
**Sample results:**

|TimeGenerated|httpStatusCode|timeTaken|errorInfo|
| -------- | -------- | -------- | -------- |
|2026-07-27 18:48:22 UTC|504|60.014|OriginTimeout|
| -------- | -------- | -------- | -------- |
|2026-07-27 18:48:22 UTC|504|60.014|OriginTimeout|
|2026-07-27 17:11:28 UTC|504|60.001|OriginTimeout|
|2026-07-27 17:06:13 UTC|504|60.001|OriginTimeout|

**What I've already ruled out:**

- Config didn't fail silently — JSON view confirms 240 is saved and provisioning state is "Succeeded"

- Not a propagation delay — this has persisted for 4 hours since the change

- Not an origin performance issue — direct calls to the origin (bypassing Front Door) succeed in ~95 seconds

- Not a caching/byte-range/Accept-Encoding issue — this is a POST to an API endpoint, not cacheable static content

**Question:** Why would Front Door enforce the default 60-second timeout when the profile's `originResponseTimeoutSeconds` is explicitly set to 240? Is there a separate setting (route-level, origin group-level) that could be overriding this, or is this a platform-side issue?

Answer 1

Hello @Jeff Olmstead

If the slow response time is expected (for example, a report generation endpoint), you can increase the timeout in Front Door.

For Azure Front Door Standard/Premium:

# Update the origin response timeout for a Front Door profile
# Maximum allowed value is 240 seconds
az afd profile update \
  --resource-group myResourceGroup \
  --profile-name myFrontDoor \
  --origin-response-timeout-seconds 120

For classic Azure Front Door, the timeout is set at the profile level:

# Update the backend timeout for classic Front Door
az network front-door update \
  --resource-group myResourceGroup \
  --name myFrontDoor \
  --send-recv-timeout 120

Please ensure that increasing the timeout means clients wait longer for a response. For user-facing endpoints, anything over 30 seconds is a poor experience. Consider using asynchronous patterns (return a 202 Accepted and poll for results) for long-running operations.

Also,

• Check backend performance Bypass Front Door and hit the backend directly (use the backend URL or IP). If it’s slow or hangs, AFD will time out and return 504. Look at logs from your app, database, or any downstream APIs to see if requests are taking longer than 30 seconds.
• Check backend health in AFD In the Azure portal, go to your Front Door profile → Backend pools → see if the backend shows as Unhealthy or intermittent health. If health probes fail, AFD may stop routing traffic or fall back to a slower path, which can also cause 504s.
• Review AFD timeout settings The default origin response timeout is 30 seconds. If your backend realistically needs more time (for example 60–120 seconds), you can increase the Origin response timeout in the Front Door profile (Standard/Premium SKUs) up to 240 seconds. This reduces 504s without changing your app code.
• Check network and security Make sure NSG rules, firewalls, WAF, or load balancers are not blocking or delaying traffic from AFD’s POPs. If AFD is routed through a private link or VNet, ensure the Private Endpoint is approved and connected.
• Use logs and ErrorInfo Look at AFD’s diagnostics / Front Door Analytics logs and filter for 504 responses plus the ErrorInfo field. If it shows OriginTimeout, you know the backend simply took too long and you either need to optimize the backend or increase the timeout.

Reference:

https://github.com/oneuptime/blog/tree/master/posts/2026-02-16-how-to-fix-504-gateway-timeout-errors-in-azure-front-door

• Troubleshoot common issues - Azure Front Door | Microsoft Learn
• Configure Azure Front Door Logs | Microsoft Learn

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

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Hello Jeff Olmstead,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that the Origin response timeout configured at 240s but requests still timing out at 60s (OriginTimeout).

Based on the information provided, this is not a configuration issue with Origin Response Timeout. Azure Front Door Standard/Premium exposes this setting only at the profile level, and there is no documented route-level, endpoint-level, or origin-group-level timeout override that would force requests back to the default timeout. Therefore, if requests consistently terminate at approximately 60 seconds, the remaining supported causes are that the request is reaching a different Front Door profile, an intermediate proxy or gateway is enforcing its own timeout, or Azure Front Door is not honoring the configured timeout.

The recommended approach is to first verify that the failing request is being processed by the same Front Door profile where originResponseTimeoutSeconds = 240 is configured. Capture the X-Azure-FDID and X-Azure-Ref response headers from the failed request and correlate them with Front Door Access Logs. At the same time, confirm that no intermediate components (such as Azure API Management, Application Gateway, Azure App Service ARR, Container Apps ingress, NGINX, or another reverse proxy) exist in the request path that could impose an independent 60-second timeout.

If those validations confirm that the request is processed by the correct Front Door profile, there are no intermediate proxies, and Front Door still returns 504 OriginTimeout after approximately 60 seconds while the origin completes successfully in approximately 95 seconds, then there are no additional configurable settings available from you to resolve this behavior. The remaining action is to engage Azure Support with the request correlation data (X-Azure-Ref, X-Azure-FDID), via your Azure Portal. Use the following references for architecture, diagnostics, and implementation steps:

https://learn.microsoft.com/azure/frontdoor/standard-premium/overview

https://learn.microsoft.com/azure/frontdoor/origin

https://learn.microsoft.com/azure/frontdoor/monitor-front-door

https://learn.microsoft.com/azure/frontdoor/troubleshoot-issues

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

---

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.