Skip to content

500/121 Timeout Signature Detection

Scenario: Client-reported HTTP 500 errors on Windows App Service (Java SE, Python on Windows, Node on Windows), suspected to be the httpPlatformHandler timeout signature. Data Source: AppServiceHTTPLogs Purpose: Enumerate every request that IIS terminated with 500.121.* so you can eyeball the URL distribution, per-request TimeTaken, and ScWin32Status extension distribution before running the aggregation queries.

flowchart TD
    A[AppServiceHTTPLogs] -->|ScStatus == 500| B[Filter 500]
    B -->|ScSubStatus == 121| C[Filter 500/121]
    C --> D[Project URL + TimeTaken + ScWin32Status]
    D --> E[Order by TimeGenerated desc]

Run It in the Portal

Paste the query below into the New Query 1 editor and press Run. The result grid returns one row per 500/121 request; on a healthy app you should see zero rows, and any non-zero result is a real timeout event worth investigating.

Query

AppServiceHTTPLogs
| where TimeGenerated > ago(24h)
| where ScStatus == 500 and ScSubStatus == 121
| project
    TimeGenerated,
    CsUriStem,
    CsMethod,
    TimeTaken_ms = TimeTaken,
    ScStatus,
    ScSubStatus,
    ScWin32Status,
    CsBytes,
    ScBytes,
    CIp
| order by TimeGenerated desc

Interpretation Notes

  • Zero rows: No httpPlatformHandler timeout activity in the last 24 hours. This is the expected steady state.
  • A handful of rows on the same URL: A specific slow endpoint is repeatedly hitting the front-end 230s ceiling. Route to endpoint-level analysis (query dependency latency, look for blocking I/O in the handler).
  • Many rows spread across many URLs, all ScWin32Status = 0: The whole app is slow and requests are hitting the 230s absolute limit. Look at plan SKU vs load, GC pauses, or downstream saturation. See the timeout cluster statistics query to confirm the 230s clustering.
  • Rows with ScWin32Status = 64: Adaptive-extension activity. See the ScWin32Status .0 vs .64 distribution query to quantify the ratio.
  • TimeTaken values well below 230000 ms: The cut is happening earlier than the front-end limit. Check whether httpPlatformHandler.requestTimeout has been reduced via a custom web.config, or whether the app is issuing an internal 500 that IIS is annotating with the same sub-status.

Lab 1 of the Windows Java httpPlatformHandler Timeout Lab demonstrated 10/10 rows with mean TimeTaken = 230001 ms, standard deviation 5 ms - a textbook front-end 230s cut with no adaptive-extension activity under serialized load.

Limitations

  • AppServiceHTTPLogs ingestion lag is typically 2-5 minutes. Rows for very recent requests may not appear immediately.
  • AppServiceHTTPLogs does not distinguish between the httpPlatformHandler reuse of 500.121 and a genuine FastCGI-hosted app's 500.121. On Windows App Service Java SE the signal is unambiguously httpPlatformHandler because there is no FastCGI worker in the stack; on other language runtimes (PHP, Python on Windows classic) FastCGI may be involved and additional context is needed.
  • The query lists individual requests but does not aggregate. For statistical characterization of the timing distribution, use the timeout cluster statistics query.
  • If the App Service is behind an upstream reverse proxy (Application Gateway, Front Door, or a custom nginx), the client-observed status code may be 502 or 504 even when this query returns 500/121 at the IIS layer. Correlate with upstream logs.

See Also

Sources