Azure API Timeout: How to Diagnose and Fix 408/504 Timeout Errors

Understanding Azure API Timeout Errors

When an Azure API call exceeds a time boundary, the failure can originate at several distinct layers, each producing a different error signature:

• Client SDK / HttpClient – throws TaskCanceledException (C#) or ECONNABORTED (Node.js) with message: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
• Azure API Management gateway – returns HTTP 504 Gateway Timeout with body { "statusCode": 504, "message": "Origin server did not respond in time." }
• Azure Load Balancer idle timeout – silently resets the TCP connection after 4 minutes of inactivity; the client sees a connection reset or SocketException.
• Azure Resource Manager (ARM) polling – returns HTTP 202 Accepted immediately but the polling loop eventually times out with CloudException: OperationTimedOut.
• Azure SQL / Cosmos DB – surfaces as SqlException: Timeout expired or RequestRateTooLargeException (429) which, if unretried, manifests as a logical timeout.

Understanding which layer fired is the mandatory first step before applying any fix.

Step 1: Identify the Timeout Layer

1a. Read the full exception chain. In .NET, always call exception.ToString() rather than .Message – the inner TaskCanceledException or SocketException reveals whether the cancellation token came from your code or the HTTP stack.

1b. Check the HTTP status code. 408 = client or server explicitly signaled timeout. 504 = intermediate proxy (APIM, Application Gateway, or Azure Front Door) gave up. A connection-reset with no status code = TCP-layer idle timeout from the Load Balancer.

1c. Pull APIM diagnostic logs. In the Azure portal go to API Management → APIs → [your API] → Test and inspect the trace, or enable Application Insights on APIM:

GET https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.ApiManagement/service/{apim}/apis/{api}/diagnostics/applicationinsights?api-version=2022-08-01

Look for backend-duration in the trace. If it is close to your forward-request timeout value, the backend is the bottleneck, not your client.

1d. Check Azure Monitor / Application Insights. Run this KQL query in Log Analytics to find all requests that exceeded 30 seconds:

requests
| where timestamp > ago(1h)
| where duration > 30000
| project timestamp, name, resultCode, duration, cloud_RoleName
| order by duration desc

Step 2: Fix Client-Side Timeouts (C# / .NET)

The default HttpClient timeout is 100 seconds. For APIs that legitimately take longer, create a named client via IHttpClientFactory:

// Program.cs / Startup.cs
builder.Services.AddHttpClient("AzureBackend", client =>
{
    client.BaseAddress = new Uri("https://myapi.azure-api.net");
    client.Timeout = TimeSpan.FromSeconds(180); // explicit, documented
})
.AddPolicyHandler(GetRetryPolicy());

static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy() =>
    HttpPolicyExtensions
        .HandleTransientHttpError()          // 5xx and network errors
        .OrResult(r => r.StatusCode == (HttpStatusCode)429)
        .WaitAndRetryAsync(
            retryCount: 4,
            sleepDurationProvider: attempt =>
                TimeSpan.FromSeconds(Math.Pow(2, attempt))   // 2, 4, 8, 16 s
                + TimeSpan.FromMilliseconds(new Random().Next(0, 500)));

Important: Set the CancellationToken on the request itself when you need per-request control, rather than mutating HttpClient.Timeout at runtime (which is not thread-safe).

Step 3: Fix APIM Gateway Timeouts

In Azure API Management, the default forward-request timeout is 300 seconds (since API version 2021+) but older services default to 60 seconds. Raise it in the inbound or backend policy:

<!-- APIM Policy (API or Operation scope) -->
<policies>
  <inbound>
    <base />
  </inbound>
  <backend>
    <forward-request timeout="180" follow-redirects="true" />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Note that the timeout attribute is in seconds and cannot exceed 230 seconds due to the underlying Azure Load Balancer constraint. If your operation needs more than 230 seconds, you must use the async pattern described in Step 4.

Step 4: Convert Long-Running Operations to Async Polling

The Azure-standard pattern for operations > 90 seconds is the REST Long-Running Operations (LRO) specification:

1. Client POSTs the request.
2. Backend immediately returns 202 Accepted with a Location or Operation-Location header pointing to a status endpoint.
3. Client polls the status endpoint (with exponential back-off) until it receives 200/201 with the final result or a terminal error.

import time, requests

def start_operation(endpoint, payload, token):
    headers = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
    r = requests.post(endpoint, json=payload, headers=headers, timeout=30)
    r.raise_for_status()
    if r.status_code == 202:
        return r.headers["Operation-Location"]
    return None  # synchronous completion

def poll_until_done(operation_url, token, max_wait=600):
    headers = {"Authorization": f"Bearer {token}"}
    elapsed = 0
    interval = 5
    while elapsed < max_wait:
        r = requests.get(operation_url, headers=headers, timeout=30)
        r.raise_for_status()
        body = r.json()
        status = body.get("status", "").lower()
        if status in ("succeeded", "failed", "canceled"):
            return body
        time.sleep(interval)
        elapsed += interval
        interval = min(interval * 1.5, 30)  # back-off up to 30 s
    raise TimeoutError(f"Operation did not complete within {max_wait}s")

Step 5: Fix Azure Function Cold-Start Timeouts

Azure Functions on the Consumption plan can take 5–15 seconds to cold-start. If your API call hits a cold instance, the cumulative latency often triggers client timeouts.

Options:

• Set "functionTimeout": "00:10:00" in host.json (max 10 min on Consumption, unlimited on Premium/Dedicated).
• Enable Always On (App Service Plan) or Pre-warmed instances (Premium plan) to eliminate cold starts.
• Use Azure Front Door health probes to keep instances warm.

Step 6: Verify the Fix in Staging

After applying changes, validate with a load test using Azure Load Testing or k6 before promoting to production:

# k6 smoke test – replace URL and token
k6 run --vus 10 --duration 60s - <<'EOF'
import http from 'k6/http';
import { check, sleep } from 'k6';

const TOKEN = __ENV.AZURE_TOKEN;
const BASE  = __ENV.API_BASE_URL;

export default function () {
  const res = http.post(`${BASE}/api/long-running`, JSON.stringify({input: 'test'}), {
    headers: { 'Authorization': `Bearer ${TOKEN}`, 'Content-Type': 'application/json' },
    timeout: '190s',
  });
  check(res, {
    'status is 200 or 202': (r) => r.status === 200 || r.status === 202,
    'no timeout':           (r) => r.status !== 408 && r.status !== 504,
  });
  sleep(1);
}
EOF