Azure Functions Flex Consumption: intermittent HTTP 503 after ~60 seconds on Entra sign-in callback

Question

Hello,I’m seeking help diagnosing recurring “The service is unavailable” responses from an Azure Function App. Reloading sometimes restores access, but the interruptions recur during normal use.The clearest captured failure is an HTTP 503 on the platform-managed Microsoft Entra sign-in callback after approximately 60 seconds.EnvironmentAzure Functions, Flex Consumption, East US.Linux, Python 3.12.Last verified configuration: 2,048 MB, maximum one instance, no always-ready instances.Built-in Microsoft Entra authentication/Easy Auth.Browser: Safari on macOS.The captured request uses the app’s native azurewebsites.net hostname.Precisely captured failure — October 2, 2026Path: /.auth/login/aad/callbackStatus: 503 Site UnavailableResponse Date header: Fri, 02 Oct 2026 16:11:38 GMT — 12:11:38 p.m. EDT.Safari Waiting: 60,177.2 ms.Time to first byte and total duration: 60,178.5 ms.Response body: The service is unavailable.Content-Type: text/html; Content-Length: 27.No correlation identifier appeared in the displayed response headers.The timestamp above is the response’s Date header, not a measured request-start time. A useful correlation window is October 2, 16:08–16:15 UTC.I have also encountered service-unavailable pages while navigating the application, submitting forms, and downloading results. However, only the callback failure has been captured at this level of detail. We have not established whether the other occurrences fail at the same authentication stage.Troubleshooting already completedFor the earlier October 1 window, 20:00–21:15 UTC:Application Insights contained successful application requests, two separate HTTP 400 responses, and no captured HTTP 5xx responses or exception records.Configuration, managed identity, Key Vault settings, host-name collision, trigger synchronization, and stuck-execution checks passed.The startup/host-health subcheck reported no failures during its narrower 20:15–21:15 UTC window.Available one-minute metrics showed CPU averages of 0–1% and peak average memory around 1.14 GiB against the configured 2 GiB. Coverage was incomplete and does not exclude brief spikes.A synchronous-timer warning referred to an invocation lasting approximately 26 ms. Durable tracing announcements were also reviewed; they did not establish runtime crashes.These checks concern October 1 and do not establish platform health during the captured October 2 failure. Likewise, absent application telemetry does not establish that no failure occurred.The sign-in callback belongs to built-in authentication, rather than a custom Python callback handler. We have not established whether the failure originates in authentication, frontend/backend routing, worker availability, networking, or another platform component. The approximately 60-second wait is an observation, not a confirmed diagnosis.Help requestedWhich supported diagnostics on Linux Flex Consumption can reveal the underlying error for this platform authentication callback?How can we distinguish an Easy Auth failure from a frontend timeout, worker startup/availability problem, or networking issue?Can a Microsoft engineer help correlate the specified window and identify which component generated the 503 and why it waited approximately 60 seconds?An Azure Standard technical support case is already open, and advanced diagnostic access has been authorized. Resource identifiers and detailed evidence can be provided privately through that case.I would appreciate targeted guidance on the next diagnostic or an appropriate escalation to Azure Functions/App Service engineering. Thank you.