Azure API Timeout: How to Fix 504, 408, and Operation Timed Out Errors

Understanding Azure API Timeout Errors

Azure surfaces timeout failures through several distinct error codes and messages depending on where in the request chain the deadline expires:

• 504 Gateway Timeout — Azure API Management (APIM) did not receive a response from the backend within the configured forward-request timeout (default: 60 seconds).
• 408 Request Timeout — The client's connection to APIM or the Azure load balancer itself expired before the server acknowledged the request.
• System.TimeoutException: The operation timed out — Thrown inside .NET code when an HttpClient or SDK call exceeds its Timeout property.
• Function host timed out after 00:05:00 — An Azure Function exceeded its functionTimeout value (default 5 min on Consumption, 30 min on Premium/Dedicated).
• Upstream connect error or disconnect/reset before headers. reset reason: connection timeout — Seen in APIM developer portal traces when the backend TCP handshake itself fails.

Each of these has a different fix. The first step is always to identify where in the chain the clock ran out.

Step 1: Locate the Timeout Boundary

1a. Check APIM diagnostic logs in Azure Monitor.

Navigate to your APIM instance → Diagnostic settings → Log Analytics workspace. Run this KQL query:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.APIMANAGEMENT"
| where Category == "GatewayLogs"
| where httpStatusCodeCategory_s == "5xx"
| project TimeGenerated, requestId_s, backendResponseCode_d, backendTime_d, totalTime_d, url_s
| order by TimeGenerated desc

If backendTime_d is close to 60000 ms and backendResponseCode_d is null, APIM timed out waiting for your backend — fix is in the APIM policy.

If backendTime_d is well under 60 s but the client still sees a 504, the issue is upstream (client → APIM leg) or a misconfigured custom domain / Front Door.

1b. Enable APIM tracing for a single request.

# Pass the Ocp-Apim-Trace header to get a trace URL back
curl -i -H "Ocp-Apim-Subscription-Key: <your-key>" \
     -H "Ocp-Apim-Trace: true" \
     "https://<apim-name>.azure-api.net/<api-path>"

# The response headers will contain:
# Ocp-Apim-Trace-Location: https://apimstxxxxxxx.blob.core.windows.net/...
# Fetch that URL for a full JSON trace showing every policy step and its duration
curl "<trace-location-url>" | python3 -m json.tool | grep -A3 'elapsed'

1c. Check Azure Function execution duration.

az monitor app-insights query \
  --app <app-insights-name> \
  --resource-group <rg> \
  --analytics-query "
    requests
    | where timestamp > ago(1h)
    | where success == false or duration > 25000
    | project timestamp, name, duration, resultCode, cloud_RoleName
    | order by duration desc
    | take 50
  "

Step 2: Fix APIM Policy Timeout

The forward-request policy element controls how long APIM waits for the backend. The default is 60 seconds.

In the Azure portal, go to your API → Design tab → select the operation → Inbound processing → edit the policy XML:

<policies>
  <inbound>
    <base />
    <!-- Increase timeout to 120 seconds for this operation -->
    <forward-request timeout="120" follow-redirects="true" />
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Warning: The Azure load balancer in front of APIM enforces a 240-second idle TCP timeout. Setting forward-request timeout above 240 is ineffective — the connection will be silently reset by the load balancer first.

If you need timeouts per-operation rather than globally, scope the policy to the operation level rather than the API or product level.

Step 3: Fix Azure Functions Timeout

For Consumption plan functions, the default functionTimeout is 5 minutes; the maximum is 10 minutes. For Premium and Dedicated (App Service) plans the default is 30 minutes and there is no enforced maximum in the runtime — but the 230-second Azure load balancer limit still applies to HTTP triggers.

Edit host.json:

{
  "version": "2.0",
  "functionTimeout": "00:10:00",
  "extensions": {
    "http": {
      "routePrefix": "api"
    }
  }
}

For operations that genuinely exceed 230 seconds over HTTP, implement the async HTTP polling pattern:

1. Client POSTs to trigger function → function starts a Durable orchestration → immediately returns 202 Accepted with a statusQueryGetUri.
2. Client polls the status URL until runtimeStatus is "Completed".
3. Client retrieves the output.

This pattern is fully supported by the DurableOrchestrationClient (now DurableClient) binding:

[FunctionName("StartLongJob")]
public static async Task<HttpResponseMessage> HttpStart(
    [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequestMessage req,
    [DurableClient] IDurableOrchestrationClient starter,
    ILogger log)
{
    string instanceId = await starter.StartNewAsync("LongJobOrchestrator", null);
    return starter.CreateCheckStatusResponse(req, instanceId);
}

Step 4: Fix Client-Side HttpClient Timeouts (.NET)

If the timeout originates inside your application code rather than the Azure infrastructure layer:

// WRONG — default Timeout is 100 seconds but is set once and cannot be changed after first use
var client = new HttpClient();
client.Timeout = TimeSpan.FromSeconds(300); // must set BEFORE first request

// CORRECT — use IHttpClientFactory with Polly retry + timeout
services.AddHttpClient("AzureBackend", c =>
{
    c.BaseAddress = new Uri("https://myapi.azure-api.net/");
    c.Timeout = TimeSpan.FromSeconds(120);
})
.AddPolicyHandler(HttpPolicyExtensions
    .HandleTransientHttpError()
    .Or<TimeoutRejectedException>()
    .WaitAndRetryAsync(3, i => TimeSpan.FromSeconds(Math.Pow(2, i))));

Step 5: Diagnose Cold-Start Latency

On Consumption plan, the first invocation after an idle period spins up a new host instance. Typical cold-start durations:

Mitigations (in order of cost):

1. Premium plan with pre-warmed instances — eliminates cold starts entirely.
2. Always-on setting (Dedicated plan) — keeps the host loaded.
3. Azure Function's "Warm" HTTP trigger — a lightweight keep-alive pinger via Azure Monitor scheduled queries or Azure Logic Apps.
4. Reduce package size — large deployment packages increase cold start time. Run func pack --build-native-deps and check the output size.

Step 6: Verify Network Path (VNet Integration)

If your APIM backend is inside a VNet or the Function uses VNet Integration, check NSG rules and DNS:

# From APIM self-hosted gateway or a VM in the same subnet:
nc -zv <backend-private-ip> 443

# Check effective NSG rules on the backend NIC:
az network nic show-effective-nsg \
  --resource-group <rg> \
  --name <nic-name> \
  --query "effectiveSecurityRules[?access=='Deny']" \
  --output table

# Verify private DNS resolution inside the VNet:
nslookup <backend-hostname> 168.63.129.16

A missing or incorrect NSG outbound rule to the backend subnet on port 443 will cause the TCP SYN to be silently dropped, resulting in a connection timeout (usually at exactly 60 s — the APIM default) rather than a fast TCP RST.