Azure Functions Python on Linux Consumption: Fix Missing Functions with Correct Packaging and Settings

Troubleshoot Azure Functions Python on a Linux Consumption plan: fix missing functions by correcting packaging, WEBSITE_RUN_FROM_PACKAGE, and storage settings.

Azure Functions on a Linux Consumption plan can silently ignore your Python endpoints if the app package is laid out incorrectly or key settings are not aligned with the deployment model. A common symptom is a Function App that starts, but no functions show up in the portal or in the environment. The good news: this is usually about packaging and configuration, not your handler logic.

Problem overview

The app was configured to run from a package hosted in Azure Storage via a SAS URL, yet the function list remained empty. The setting looked like this:

WEBSITE_RUN_FROM_PACKAGE = https://testfunc007.blob.core.windows.net/test123/HttpTrigger1.zip?sp=r&st=2025-05-28T02:39:29Z&se=2025-09-05T10:39:29Z&spr=https&sv=2024-11-04&sr=b&sig=zFH1y9KVNlibedwFVySop%2BbCnsSduX5UNrbwnVn7i8M%3D

The expected Python function did not appear during indexing. The code itself was a simple HTTP trigger using the Python programming model.

Code example that should have been discovered

The handler below is a minimal HTTP route. If the package is correct and settings are in place, this endpoint is discoverable and callable.

import azure.functions as azf
import logging as log

fa = azf.FunctionApp(http_auth_level=azf.AuthLevel.ANONYMOUS)

@fa.route(route="http_trigger")
def ping(req: azf.HttpRequest) -> azf.HttpResponse:
    log.info("Hello Rithwik")
    return azf.HttpResponse("Rithwik", status_code=200)

Why the function wasn’t showing up

The indexing relies on a proper package layout and specific app settings. When the archive structure does not match what the Python worker expects at the root, the Function App boots without discovering any endpoints. Additionally, the deployment approach matters. Using a direct SAS URL for the package without aligning the Function App settings for a Consumption plan can lead to the same “no functions found” outcome.

Worker indexing is explicitly enabled here:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "AzureWebJobsFeatureFlags": "EnableWorkerIndexing"
  }
}

If the archive is structured incorrectly, indexing completes but returns nothing, which looks like the app ignored your Python code. There was also confusion around storage resources in the discussion. Do not mix up a file share name and a blob container name; they are different things and are referenced differently by related settings. That confusion alone can derail packaging and deployment.

The fix that worked

Two pieces unlocked discovery: packaging the project at the correct root layout and setting the right configuration for a Consumption plan. The working archive had this shape at the top level of the zip:

<root>/
├── .vscode/
├── .venv/
├── .funcignore
├── .gitignore
├── function_app.py
├── host.json
├── local.settings.json
├── requirements.txt
└── __pycache__/

Before deployment, the app setting was added like this:

"WEBSITE_RUN_FROM_PACKAGE": "1"

On a Consumption plan, the following setting was also required:

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

After deploying the zip, the functions appeared. Later, the value of the run-from-package setting changed in the portal; the important part is that discovery began working once the package and settings were corrected.

The deployment was performed without VS Code using the CLI:

az functionapp deployment source config-zip -g "resgrpname" -n "funcanme" --src "test.zip"

The function file remained as shown above; for completeness, here is the same handler that the worker successfully discovered once the layout and settings were corrected:

import azure.functions as azf
import logging as log

fa = azf.FunctionApp(http_auth_level=azf.AuthLevel.ANONYMOUS)

@fa.route(route="http_trigger")
def ping(req: azf.HttpRequest) -> azf.HttpResponse:
    log.info("Hello Rithwik")
    return azf.HttpResponse("Rithwik", status_code=200)

Why this matters

In serverless environments, discovery is as critical as the code itself. If the runtime cannot index functions, you will end up debugging a “missing function” problem that has nothing to do with your handler. Ensuring the correct zip layout and aligning deployment settings to the plan type saves hours of trial and error and avoids misleading storage configuration issues.

Practical takeaways

Keep host.json and your Python entry point at the root of the archive, not nested. Enable run-from-package with a simple “1” before you push the zip, and include the Consumption-specific storage setting so the platform can do its job. When deploying by CLI, use config-zip against a properly built archive. Finally, treat file share names and container names as distinct; using the wrong resource in a setting leads straight back to missing functions.

Conclusion

If your Python Function App on a Linux Consumption plan is running but shows no functions, start with packaging and configuration. A clean root-level project structure, WEBSITE_RUN_FROM_PACKAGE set to 1 prior to deployment, and the required storage setting for Consumption were sufficient to make the endpoints appear. With those in place, even a minimal HTTP trigger is indexed and callable immediately after a zip deployment.