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 15,375 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 eklay-rg --name eklay-quote-agent

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 15,375 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.