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

Question

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

1. 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?
2. Which customer-visible logs, metrics, or detectors can distinguish frontend routing, instance allocation, host readiness, and Python worker readiness for an individual failed request?
3. 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?
4. 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.

Answer 1

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

---

• Create and manage function apps in the Flex Consumption plan (programming-language-python)
• Reliability in Azure Functions (flex-consumption)
• Why would a Timer Triggered Azure Function in Flex Consumption stop invoking without any errors and only resume after a manual restart? - Microsoft Q&A
• Inquiry Regarding Azure Functions Service Stability, 503 Service Unavailable - Microsoft Q&A