Azure Functions Flex Consumption — alternating HTTP 503 after 60 seconds and host.json permission errors

Hi Jerald,

Thank you for your guidance. We've now completed further diagnostics and have some useful findings.

We enabled Application Insights and configured Host.Results and the default logging level to Information. We also enabled FunctionAppLogs with a dedicated Log Analytics workspace.

The issue persists. Our latest controlled read-only test returned:

HTTP 200 in 7.92 seconds

HTTP 200 in 0.50 seconds

HTTP 503 in 60.18 seconds

HTTP 200 in 0.52 seconds

Application Insights recorded some successful HTTP 200 requests but none of the 503 failures. AppTraces, AppExceptions and FunctionAppLogs returned no matching records, despite detailed logging being enabled.

The latest deployment ZIP has the correct 0644 permissions and is marked active in kudu-state.json. The older released-package.zip has incorrect 0600 permissions. The problem also persists at 2,048 MB memory.

This suggests the failures may be occurring before requests reach the Functions runtime, although we cannot establish that conclusively from the available telemetry.

Given these findings, could you advise how to investigate front-end routing, language-worker startup or stale package mounting at the Azure platform level? Is there a further diagnostic we can access without a paid support plan?

Many thanks,

Henry

Hello Henry Jakins,

Greetings! Thanks for raising this question in the Q&A forum.

I can't tell you with certainty from the outside whether this is a worker startup, package mounting or deployment activation problem. Here is how I read it, and how to confirm it with platform diagnostics.

The pattern you describe fits a worker that sometimes cannot load the deployment package or start the Functions host. A fixed 60 second wait followed by a 503 usually means the front end gave up waiting for an instance that never became ready. Requests that land on a healthy instance return 200 in about a second. The host.json access denied errors, together with the 0600 permissions on the older released-package.zip, suggest some instances may be loading that older package. A 0600 file is readable only by its owner, and the worker process on Flex Consumption may run as a different user. The other possibility is that a stale instance simply kept the old package mounted. You are right that the earlier errors predate the latest deployment, so this has not been proven yet.

Here are the steps I would follow:

1. Check whether the 503s are tied to specific instances. In Application Insights, run a query like the one below. If failures cluster on certain cloud_RoleInstance values, a bad or stale worker is the likely cause.

requests | where timestamp > ago(24h) | summarize count(), avg(duration) by resultCode, cloud_RoleInstance | order by count_ desc

1. Look for host startup failures. Run the query below and look for repeated host start attempts or the System.IO.IOException and access denied messages after your latest deployment time.

traces | where timestamp > ago(24h) | where message has_any ("host.json", "Access to the path", "Host started", "Host initialization", "Stopping host") | order by timestamp desc

1. Re-publish from a clean package with correct permissions. Rebuild the ZIP so host.json, function_app.py and requirements.txt are 0644. Zipping from a Windows or macOS tool can sometimes produce odd permission bits. Then deploy with Core Tools or the CLI so the platform creates a new deployment package and a fresh set of workers.

func azure functionapp publish <APP_NAME>

or

az functionapp deployment source config-zip -g <RESOURCE_GROUP> -n <APP_NAME> --src <PACKAGE>.zip

Make sure the old package is no longer referenced. On Flex Consumption the package is stored in the deployment container configured under the app's deployment storage settings. Confirm the container holds only the package you expect, and that the app's identity or connection string can read it. Do not add WEBSITE_RUN_FROM_PACKAGE to a Flex Consumption app, because it is not supported there. Remove it if it was added.

Restart the app and test after it has fully started. Start the app, allow a couple of minutes, and then send a series of requests. If the alternating 503 and 200 pattern is gone, the older package or a stale instance was the cause.

1. Check storage access and networking. If the storage account for the deployment container has a firewall, private endpoint or restricted network access, confirm the function app's VNet integration and identity permissions (for example Storage Blob Data Contributor or Owner on the container). A blocked storage path can also show up as access denied on host.json.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,
Jerald Felix.