Intermittent 60-second HTTP 503s on Azure Functions Flex Consumption with no failed invocations recorded

Question

Intermittent 60-second HTTP 503s on Azure Functions Flex Consumption with no failed invocations recorded

aldol 0

Environment

Azure Functions v4, Python programming model v2
Linux Flex Consumption FC1, Python 3.14
Korea Central, On Demand, Always Ready = 0
Student, non-production environment with Basic support

Symptom

A simple non-inference health endpoint intermittently returns HTTP 503 after approximately 60 seconds. The same endpoint also succeeds in about 100 ms, or about 4 seconds with a newly observed process. The exact internal cause remains unknown.

Reproduction

One diagnostic sequence contained six non-inference HTTP requests:

Test	Route	HTTP	Total duration
1	health-lite	200	136.704 ms
2	health-lite	503	60,075.897 ms
3	health-runtime	200	114.876 ms
4	health-import	503	60,068.037 ms
5	health-lite, after idle	200	4,043.227 ms
6	health-lite	503	60,064.627 ms

These tests made zero GPT/OpenAI inference calls. The health-lite handler returns fixed JSON; the runtime route returns local process information; the import route uses the application's import context without acquiring tokens or calling a model.

Important evidence

For the relevant failure windows, Azure platform detector aggregates showed HTTP 5xx = 3. Function invocation aggregates showed successful invocations = 3 and failed invocations = 0.

The 503 responses had no application diagnostic header or invocation ID. This makes a failure before invocation dispatch or Python handler entry a possibility, but I could not verify handler non-entry. These are aggregate observations, not request-level traces. Platform total HTTP hits were 8, so I cannot equate all platform hits with the six client tests; the two additional hits are unexplained.

Other observations

The successful cold-ish request reported a new process marker, about 1.7 seconds of module import time, and about 0.32 ms of handler execution time. This does not prove that cold start caused the failures.
Platform diagnostics reported Python worker exit code 143. Available detailed timestamps were after the 503 failures; the termination initiator and causal relationship remain unverified.
No directly visible host startup/readiness failure was found for the relevant windows. This is a limit of the accessible evidence, not proof that no such event occurred.
Application Insights was not configured during the original reproduction; requests/traces tables were not queried.
The application's configured functionTimeout was 60 seconds. Without evidence that a failed request entered invocation execution, or an execution-timeout log, I cannot attribute the 60-second pattern to that setting.

What these tests exclude

The tested health paths performed no GPT inference, Managed Identity token acquisition, or external API calls. Azure OpenAI inference latency therefore does not explain these health failures. Application module imports and Azure platform initialization remain separate considerations.

Questions for Microsoft / the community

Is there a known Flex Consumption request-routing or readiness path that can return a 503 after about 60 seconds before invocation dispatch? What evidence would distinguish it from an invocation execution timeout?
Which customer-visible logs, metrics, or detectors can distinguish frontend routing, instance allocation, host readiness, and Python worker readiness for an individual failed request?
If Microsoft internal trace correlation is required, what escalation path is recommended for a student/Basic-support user whose technical support form requires a paid plan?
Before enabling Always Ready, what more direct evidence should be collected to determine whether it would address this particular failure pattern?

Resource/account identifiers and raw diagnostic archives are intentionally omitted from this public question. Detailed correlation evidence can be considered through an appropriate private Microsoft support channel.

0 comments

2 answers

Your answer

Answer 1

Hi @aldol ,

Thank you for reaching out to Microsoft Q & A !

The strongest diagnostic signal is that all three failed requests ended at almost exactly 60 seconds:

60,075 ms
60,068 ms
60,065 ms

For Flex Consumption, the documented default function execution timeout is 30 minutes. Microsoft also documents a separate, non-configurable 60-second timeout for the language-specific worker process to start. See Function app timeout duration.

1. Determine whether functionTimeout is involved

Temporarily change functionTimeout in host.json from 00:01:00 to 00:02:00, redeploy, and repeat the same controlled health requests.

If the failures move from approximately 60 seconds to 120 seconds, the configured execution timeout is influencing the behavior, even though the failures are not appearing in the failed-invocation aggregate.
If the failures remain close to 60 seconds, the configured execution timeout is unlikely to be the boundary. The documented 60-second language-worker startup timeout then becomes relevant, although platform-side correlation is required to confirm the exact stage.

2. Distinguish an execution failure from a pre-dispatch or worker-readiness failure

A 503 response without an invocation ID or failed-invocation record is consistent with the request failing before the Python handler ran, but it does not prove whether the failure occurred during front-end routing, instance allocation, host readiness, or Python worker startup.

Enable Application Insights, reproduce the issue, and correlate the precise UTC failure timestamps across:

requests
traces
exceptions
dependencies
FunctionAppLogs, if Application Insights telemetry is incomplete
AzureActivity, for control-plane operations during the same period

The reported worker exit code 143 means that the Linux process received SIGTERM and was asked to terminate. However, timestamp correlation is still required before concluding that the worker termination caused the affected requests.

3. What the current evidence supports

The controlled health routes did not perform Azure OpenAI inference, acquire tokens, or call external APIs. Those dependencies therefore do not explain the reproduced failures.

Always Ready instances can reduce exposure to startup-related delays, but I would treat Always Ready as a mitigation test rather than evidence of the root cause.

If the two-minute timeout test still fails at approximately 60 seconds and no invocation-level telemetry is generated, platform-side investigation is the appropriate next step. Because the subscription currently has Basic support, opening a technical support request requires an eligible paid Azure support plan.

Please post the result of the two-minute timeout test, specifically whether the failure remains near 60 seconds or moves to approximately 120 seconds.Hi Aldol,

The strongest diagnostic signal is that all three failed requests ended at almost exactly 60 seconds:

60,075 ms
60,068 ms
60,065 ms

Please "Upvote the Answer" if this information helped you. This will help us and others in the community as well.

Answer 2

The available evidence fits a failure before function invocation dispatch more than an in-handler failure.

Why the 60-second 503 can happen without failed invocations
- On Flex Consumption, Application Insights is the first place to investigate when there are dependency timeouts, DNS failures, or other connectivity symptoms.
- The documented telemetry split is important here:
  - requests shows HTTP invocations that reached the app.
  - traces shows runtime, host, and scale-controller logs, including deployment initialization details on Flex Consumption.
  - exceptions shows runtime and user exceptions.
  - FunctionAppLogs helps when Application Insights data is missing or incomplete, including host-level issues.
  - AzureActivity helps diagnose control-plane operations and trigger registration issues.
- A 503 with no invocation ID and no failed invocation aggregate is consistent with a request failing before the Python handler ran, but the current evidence does not prove the exact stage.
How to distinguish pre-dispatch failure from execution timeout Collect request-correlated telemetry in Application Insights and compare these signals:
- If the request reached invocation execution: expect evidence in requests, and possibly matching traces or exceptions for the same time window.
- If the failure happened before dispatch or readiness completed: expect missing or incomplete invocation evidence, while traces, FunctionAppLogs, or platform-level logs may still show host startup, listener, trigger, or readiness-related activity.
- For Flex Consumption specifically, traces is the documented place to look for host startup problems, deployment failures, and DNS failures that surface through host or dependency logs.

Customer-visible logs and detectors to use next After enabling Application Insights, use the Logs experience and query these tables for the exact failure window:

Host startup or deployment failures

   traces
   | where timestamp > ago(1d)
   | where cloud_RoleName == "<APP_NAME>"
   | where message contains "Starting" or message contains "host"
   | project timestamp, message, customDimensions
   | order by timestamp desc

HTTP request timing and result codes

   requests
   | where timestamp > ago(1h)
   | where cloud_RoleName == "<APP_NAME>"
   | project timestamp, name, resultCode, duration, success, url, operation_Name
   | order by timestamp desc

Exceptions grouped by type

   exceptions
   | where timestamp > ago(1d)
   | where cloud_RoleName == "<APP_NAME>"
   | summarize count() by type, innermostMessage
   | order by count_ desc

Outbound dependency failures

   dependencies
   | where timestamp > ago(2h)
   | where cloud_RoleName == "<APP_NAME>"
   | where success == false
   | project timestamp, target, resultCode, duration, type, data

Also review:

FunctionAppLogs when Application Insights data is missing or incomplete.
AzureActivity for start, stop, sync triggers, delete, and list keys operations.

What the current evidence does and does not support
- The health routes excluding GPT inference, token acquisition, and external API calls does rule out those external calls as the direct cause of those specific failures.
- The 60-second pattern alone does not establish that functionTimeout caused the 503. The documented guidance says platform retries cover transient faults for triggers and bindings, but persistent failures such as misconfiguration are not retried automatically.
- Python worker exit code 143 and later unhealthy-process observations may be relevant, but the available evidence does not establish causality for the failed requests.
Before enabling Always Ready Collect direct evidence first:
1. Enable Application Insights.
2. Reproduce the issue.
3. Query requests for the failed timestamps.
4. Query traces for host startup, host lifecycle, and readiness-adjacent messages in the same window.
5. Check FunctionAppLogs if Application Insights is incomplete.
6. Check AzureActivity for any control-plane events around the failures.
This will separate:
- request reached app vs did not reach app,
- host started vs host not ready,
- Python code exception vs platform/host path issue.
Known related patterns in context Similar Flex Consumption cases in Q&A show that when there are no invocations or logs and behavior resumes after restart, the issue can indicate the Functions host stopped processing rather than a code or schedule problem. Another Q&A notes temporary 503s can also occur during platform issues. Those examples are not proof of the same root cause here, but they support checking host lifecycle and platform behavior before attributing the issue to application code.

The strongest next step is request-window correlation in Application Insights. That is the documented customer-visible path to distinguish HTTP request arrival, host startup behavior, exceptions, dependency behavior, and missing telemetry cases on Flex Consumption.