Problem type: Availability Problem subtype: Function App down or reporting errors Severity: C — Minimal impact (internal automation, no external users)

Question

Problem type: Availability Problem subtype: Function App down or reporting errors Severity: C — Minimal impact (internal automation, no external users)

Matt O'Brien 0

Likely related to maintenance event 4QL8-81Z (End of Routine Planned Maintenance for App Service in East US, completed earlier today). The Function App eklay-quote-agent is in East US and has been returning persistent 503 since deployment attempts that coincided with this maintenance window. The portal notification described "a brief drop in connectivity for a few seconds," but the host has been wedged at 503 for many hours and does not recover across restarts, redeploys, or a full delete-and-recreate of the Function App.

SYMPTOM

Site root https://eklay-quote-agent.azurewebsites.net returns HTTP 503 ServiceUnavailable continuously
az functionapp function list returns "Bad Request" (host management API unavailable)
Three timer-triggered functions in function_app.py are never invoked
No application logs surface in az webapp log tail or via Kudu

RESOURCE

Subscription: Pay-As-You-Go
Resource group: [PII removed]
Function App: [PII removed]
Region: East US
Plan: Linux Consumption, Python 3.11, v2 programming model

VERIFIED CONFIGURATION (all correct)

WEBSITE_RUN_FROM_PACKAGE = 1
FUNCTIONS_WORKER_RUNTIME = python
FUNCTIONS_EXTENSION_VERSION = ~4
AzureWebJobsStorage set and reachable (storage account [PII removed], all four required containers present: azure-webjobs-hosts, azure-webjobs-secrets, quote-agent-state, scm-releases)
AzureWebJobsFeatureFlags = EnableWorkerIndexing (required for Python v2 model)
linuxFxVersion = Python|3.11
Deployed package present in scm-releases: scm-latest-eklay-quote-agent.zip, ~28.78 MB, last modified 2026-05-13T01:56:23Z

STEPS ALREADY ATTEMPTED

Deploy via az functionapp deployment source config-zip --build-remote true — host stayed 503
Full recreate: deleted the Function App, created fresh, repopulated all settings — same 503
Deploy via func azure functionapp publish eklay-quote-agent --python --build remote — Oryx remote build completed successfully, package uploaded to scm-releases, host still 503
Set WEBSITE_RUN_FROM_PACKAGE=1 (was cleared by func publish) and restarted — still 503 after extended cold-start window
SCM Basic Auth enabled; storage account reachability verified; all settings populated; linuxFxVersion confirmed

REQUEST

Please investigate the underlying host startup failure and provide the worker initialization error. The Kudu API and standard log channels are not surfacing diagnostic data on this plan, which is itself a clue that the platform is not in a healthy state. Specifically asking whether maintenance event 4QL8-81Z is implicated, and whether a platform-side recovery action is available.

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-05-13T15:12:10.7366667+00:00
Hi @Matt O'Brien ,

Thanks for reaching out to Microsoft Q&A.

Since you’ve already validated all your app settings, storage connectivity, remote builds, restarts and even a full delete/recreate, it’s likely a platform‐side issue that got wedged during the East US maintenance event (4QL8-81Z). Here’s how you can dig a bit deeper and what your next steps should be:

Use the “Diagnose and solve problems” blade in the portal

In the Function App > Diagnose and solve problems > search for “Function App Down or Reporting Errors (Preview)”.

This built-in detector will run key checks (host startup, storage, runtime version, networking) and may surface a platform error you can’t see in Kudu.

Enable file‐based logging for host startup errors

In host.json, add or set:
"logging": { "fileLoggingMode": "Always" }

Restart the app, then browse to SCM → LogFiles → Application → Functions → Host to pull down the host logs.

Grab the Event Log XML

Even on Linux consumption your Eventlog.xml can contain clues: Browse to SCM → LogFiles → Eventlog.xml and look for failures during the latest startup.

Query Application Insights (if enabled)

Run a Kusto query against your AppInsights instance:
traces | where customDimensions.Category == "Host.Startup" | where severityLevel == "Error"

Also check exceptions for any worker initialization exceptions.

Run the Network Validator (if you have VNet integration enabled)

Portal → Diagnose and solve problems → Connectivity Troubleshooter

Although you’re on Consumption, this can highlight DNS or outbound issues if you ever move to a Premium plan.

Gather deeper logs via CLI

az webapp log download --resource-group rgname --name appname

Inspect the zip for any hidden startup failures.

Because you’re not seeing any host‐startup errors and the outage began immediately after the maintenance event, this strongly points to a wedged host node on the platform side. I recommend opening a Support Request (Premium or Standard) and referencing the maintenance event ID (4QL8-81Z) so the Azure compute team can unstick your host and share the underlying worker initialization error.
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-05-14T09:47:50.22+00:00

Hi @Matt O'Brien, following up to see if you had a chance to check the above response and if it was helpful. Please let me know if you have any questions.

1 answer

Your answer

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-05-14T09:47:50.22+00:00

Hi @Matt O'Brien, following up to see if you had a chance to check the above response and if it was helpful. Please let me know if you have any questions.

Answer 1

Hi Pravallika — thanks for the suggestions, closing the loop on this one.

The issue was resolved on 2026-05-13. Quick post-mortem in case it's useful for others hitting a similar wedge:

Diagnostics during the outage. The detectors you pointed to weren't reachable while the host was in this state — "Function App Down or Reporting Errors" in the Diagnose-and-Solve blade returned no data, Kudu file logging (host.json fileLoggingMode: Always) produced no startup logs because the worker never came up far enough to write any, App Insights traces was empty for the affected window, and az webapp log download returned an empty archive. az functionapp function list continued to return "Bad Request" against the live host. These channels all going silent simultaneously was itself the strongest signal that the host node was wedged at a layer below where customer-side instrumentation could see.

Resolution. We didn't manage to recover the Linux Consumption instance. After confirming with a second redeploy that the host was not going to self-heal, we recreated the Function App on the Flex Consumption plan (FC1, East US) — same Python 3.11 code, same storage account, same identity wiring, fresh app resource. The new app picked up the package on first deploy, the three timer triggers registered immediately, and it's been running on its hourly/SOD/EOD schedule cleanly since.

Takeaway. For future tickets in this shape: if a Linux Consumption Python app lands in a persistent 503 where Kudu, App Insights, and ARM management APIs are all dark at the same time, in our case the recovery path was to abandon the plan rather than repair the wedged instance. Flex Consumption is the modern Python target anyway, so the migration was overdue.

Appreciate the prompt response on this. Marking as resolved.

— Matt