Flex Consumption (FC1) Function App shows 0 functions found after successful deployment — no errors logged

Question

Flex Consumption (FC1) Function App shows 0 functions found after successful deployment — no errors logged

Serge Zuidinga 20

After a Flex Consumption (FC1) deployment that Azure itself reports as Succeeded (Active), every function host instance that starts afterward indexes 0 functions, and all HTTP routes return 404. There are no errors or exceptions anywhere in host or worker logs to explain it — the failure is completely silent.

Environment

Python 3.12, out-of-process worker
Host 4.1052.200.26352, extension bundle 4.37.1, functions extension version ~4
Deployed via GitHub Actions, Azure/functions-action@v1, remote-build, sku: flexconsumption
Region: West Europe

What happened

Deployment f3f6b40 completed normally — Kudu pipeline reported every step (extract, build, package, upload, sync triggers) as completed, and Deployment Center marked it Succeeded (Active) at 11:41:21 UTC.

Over the following ~8 minutes, three separate Flex Consumption instances started up (HostInstanceIds 679cef83, ef66e79f, 34e98056). Every single one logged the same sequence:

Loading functions metadata
Reading functions metadata (Custom)
0 functions found (Custom)
0 functions loaded
Generating 0 job function(s)
No job functions found. Try making your job classes and methods public...

Calling GET /api/StorageHealthCheck with a valid function key returns 404, consistent with the host genuinely having zero registered functions.

What I've ruled out

App code bug — no exceptions or tracebacks anywhere in traces or exceptions for the entire startup window, on any instance
Incomplete deployment — Kudu reports every pipeline step completed successfully
Telemetry lag — confirmed via direct HTTP call, not just via Application Insights
One-off instance issue — reproduced independently on three separate HostInstanceIds

This is consistent behavior I saw a few months ago on the same app, which is why it was temporarily migrated to a B1 App Service plan as a workaround. Reverting to FC1 to gather clean evidence reproduced it immediately and consistently.

Question: has anyone seen the out-of-process ("Custom") metadata provider silently return 0 functions on Flex Consumption after a deployment the platform itself reports as active? Is there a known issue or a diagnostic step that would surface why the worker-to-host handshake for function metadata is failing, given nothing is logged on either side?After a Flex Consumption (FC1) deployment that Azure itself reports as Succeeded (Active), every function host instance that starts afterward indexes 0 functions, and all HTTP routes return 404. There are no errors or exceptions anywhere in host or worker logs to explain it — the failure is completely silent.

Environment

Python 3.12, out-of-process worker
Host 4.1052.200.26352, extension bundle 4.37.1, functions extension version ~4
Deployed via GitHub Actions, Azure/functions-action@v1, remote-build, sku: flexconsumption
Region: West Europe

What happened

Deployment f3f6b40 completed normally — Kudu pipeline reported every step (extract, build, package, upload, sync triggers) as completed, and Deployment Center marked it Succeeded (Active) at 11:41:21 UTC.

Over the following ~8 minutes, three separate Flex Consumption instances started up (HostInstanceIds 679cef83, ef66e79f, 34e98056). Every single one logged the same sequence:

Loading functions metadata
Reading functions metadata (Custom)
0 functions found (Custom)
0 functions loaded
Generating 0 job function(s)
No job functions found. Try making your job classes and methods public...

Calling GET /api/StorageHealthCheck with a valid function key returns 404, consistent with the host genuinely having zero registered functions.

What I've ruled out

App code bug — no exceptions or tracebacks anywhere in traces or exceptions for the entire startup window, on any instance
Incomplete deployment — Kudu reports every pipeline step completed successfully
Telemetry lag — confirmed via direct HTTP call, not just via Application Insights
One-off instance issue — reproduced independently on three separate HostInstanceIds

This is consistent behavior I saw a few months ago on the same app, which is why it was temporarily migrated to a B1 App Service plan as a workaround. Reverting to FC1 to gather clean evidence reproduced it immediately and consistently.

Question: has anyone seen the out-of-process ("Custom") metadata provider silently return 0 functions on Flex Consumption after a deployment the platform itself reports as active? Is there a known issue or a diagnostic step that would surface why the worker-to-host handshake for function metadata is failing, given nothing is logged on either side?

0 comments

Answer accepted by question author

Jose Benjamin Solis Nolasco 10,891 Volunteer Moderator

Welcome to Microsoft Q&A,

Hello @Serge Zuidinga I hope you are doing well,

Thank you for the detailed troubleshooting. The fact that the deployment is reported as successful but multiple Flex Consumption instances consistently start with 0 functions found, without worker or host exceptions, is important.

Since this is a Flex Consumption app using Python remote build, I would first verify the deployment package and trigger synchronization rather than assume the application code is the cause. Microsoft documents that Flex Consumption uses the One Deploy model and that the deployed package must contain the files and dependencies required by the function app.

I recommend:

Run the Flex Consumption Deployment diagnostic from Diagnose and solve problems and check the package/deployment status.

Confirm that the deployed package contains the expected application files, including host.json, your Python function code, and the dependencies produced by the remote build.

Verify that the deployment completed trigger synchronization. Microsoft notes that Flex Consumption deployments require trigger synchronization, particularly when the deployment package changes.

Since you are using GitHub Actions with remote-build: true, confirm that the remote build completed successfully. This is the documented deployment approach for Python on Flex Consumption.

I would not recommend adding an arbitrary dependency to requirements.txt just to force Oryx to behave differently. There is not enough evidence in the information provided to conclude that this is the cause.

If the deployment package is correct, trigger synchronization completes successfully, and multiple new instances still consistently report 0 functions found, then the behavior warrants further investigation by Microsoft, particularly given that you have reproduced it across multiple HostInstanceIds.

When opening a support request, include the deployment ID, HostInstanceIds, timestamps, region, runtime/host versions, and the relevant deployment and host logs. This will allow the engineering team to investigate the platform-side specialization and function indexing behavior.

If my answer helped you, please consider marking it as accepted. This helps others in the community find similar solutions.

Serge Zuidinga 20 Reputation points

2026-08-07T19:56:28.93+00:00

The root cause was the entry point filename. The Python v2 programming model's worker imports a file named function_app.py at startup to discover the FunctionApp instance — my app's entry point was named main.py instead, with no scriptFile/entryPoint override in host.json pointing at it. That's why the worker reported 0 functions found with no error: it wasn't failing to read the code, it simply never looked at the file containing it.

Fix: renamed main.py → function_app.py, no code changes needed, redeployed via the same GitHub Actions pipeline. All four functions (three HTTP-triggered, one Event Grid-triggered) now show as Enabled in the portal, and a direct call to one of the HTTP endpoints returns a real 200 with a valid response body — confirmed end to end, not just a portal listing.

One nuance worth flagging for anyone finding this later: I came across Azure/azure-functions-python-worker#1808, where someone hit the identical symptom (0 functions, silent, Flex Consumption and Basic plan) despite already using a correctly named function_app.py. So this fix isn't universal — the filename convention clearly matters, but it may not be the only path to this failure mode. If you're hitting this and you're already using function_app.py, this specific fix won't help, and the underlying issue may be broader than a naming mismatch.

Thanks for pushing on this rather than assuming a platform bug outright — the elimination checklist was the right call and led somewhere concrete.
Serge Zuidinga 20 Reputation points

2026-08-07T20:00:36.61+00:00

My previous comment (please see my additional answer) was deleted because I apparently breached the code of conduct.

1 additional answer

Your answer

Serge Zuidinga 20 Reputation points

2026-08-07T19:56:28.93+00:00

The root cause was the entry point filename. The Python v2 programming model's worker imports a file named function_app.py at startup to discover the FunctionApp instance — my app's entry point was named main.py instead, with no scriptFile/entryPoint override in host.json pointing at it. That's why the worker reported 0 functions found with no error: it wasn't failing to read the code, it simply never looked at the file containing it.

Fix: renamed main.py → function_app.py, no code changes needed, redeployed via the same GitHub Actions pipeline. All four functions (three HTTP-triggered, one Event Grid-triggered) now show as Enabled in the portal, and a direct call to one of the HTTP endpoints returns a real 200 with a valid response body — confirmed end to end, not just a portal listing.

One nuance worth flagging for anyone finding this later: I came across Azure/azure-functions-python-worker#1808, where someone hit the identical symptom (0 functions, silent, Flex Consumption and Basic plan) despite already using a correctly named function_app.py. So this fix isn't universal — the filename convention clearly matters, but it may not be the only path to this failure mode. If you're hitting this and you're already using function_app.py, this specific fix won't help, and the underlying issue may be broader than a naming mismatch.

Thanks for pushing on this rather than assuming a platform bug outright — the elimination checklist was the right call and led somewhere concrete.
Serge Zuidinga 20 Reputation points

2026-08-07T20:00:36.61+00:00

My previous comment (please see my additional answer) was deleted because I apparently breached the code of conduct.

Answer 1

The root cause was the entry point filename. The Python v2 programming model's worker imports a file named function_app.py at startup to discover the FunctionApp instance — my app's entry point was named main.py instead, with no scriptFile/entryPoint override in host.json pointing at it. That's why the worker reported 0 functions found with no error: it wasn't failing to read the code; it simply never looked at the file containing it.

Fix: renamed main.py → function_app.py, no code changes needed, redeployed via the same GitHub Actions pipeline. All four functions (three HTTP-triggered, one Event Grid-triggered) now show as Enabled in the portal, and a direct call to one of the HTTP endpoints returns a real 200 with a valid response body — confirmed end to end, not just a portal listing.

One nuance worth flagging for anyone finding this later: I came across Azure/azure-functions-python-worker#1808, where someone hit the identical symptom (0 functions, silent, Flex Consumption and Basic plan) despite already using a correctly named function_app.py. So, this fix isn't universal — the filename convention clearly matters, but it may not be the only path to this failure mode. If you're hitting this and you're already using function_app.py, this specific fix won't help, and the underlying issue may be broader than a naming mismatch.

Thanks for pushing on this rather than assuming a platform bug outright — the elimination checklist was the right call and led somewhere concrete.