Azure Functions Python: why are DEBUG and CRITICAL logs ingested as Informational in FunctionAppLogs?

Question

Azure Functions Python: why are DEBUG and CRITICAL logs ingested as Informational in FunctionAppLogs?

Wessel Vonk 45

I am seeing unexpected severity mapping for Python logs in Azure Functions.

In my Function App, INFO, WARNING, and ERROR are ingested correctly in Log Analytics. However, DEBUG logs are either missing or appear as Informational, and CRITICAL logs are ingested as Informational instead of Critical.

The Python LogRecord itself appears to be correct before emission: record.levelname + record.levelno is correct.

The issue seems to happen after the log is emitted.

Observed behavior:

INFO -> Informational
WARNING -> Warning
ERROR -> Error
CRITICAL -> Informational
DEBUG -> Informational

These logs are coming from an Azure Functions Python app and appear in the FunctionAppLogs table with category Host.Function.Console.

Q: Is this expected behavior for Python logging in Azure Functions, specifically for logs ingested through Host.Function.Console? Is there an official way to preserve DEBUG and CRITICAL as proper severity levels in Log Analytics?

Gursimran Singh 160 Reputation points Microsoft External Staff Moderator

2026-07-15T15:13:48.5566667+00:00

Hi @Wessel Vonk ,

Thank you for the details provided.

To help us further investigate, could you please share the complete host.json file currently deployed to the Function App?

Azure Functions logging behavior is governed by the log level configuration defined in host.json, and restrictive log level settings can suppress lower-severity logs such as DEBUG before they are sent to Application Insights. Based on Microsoft documentation, these settings apply to the Functions logging pipeline and can impact which log levels are emitted. [https://le...og-levels)])

If preferred, you can share the host.json configuration in a private message here.

Once we review the deployed configuration, we can determine whether the observed behavior is related to the current logging policy.

1 answer

Your answer

Gursimran Singh 160 Reputation points Microsoft External Staff Moderator

2026-07-15T15:13:48.5566667+00:00

Hi @Wessel Vonk ,

Thank you for the details provided.

To help us further investigate, could you please share the complete host.json file currently deployed to the Function App?

Azure Functions logging behavior is governed by the log level configuration defined in host.json, and restrictive log level settings can suppress lower-severity logs such as DEBUG before they are sent to Application Insights. Based on Microsoft documentation, these settings apply to the Functions logging pipeline and can impact which log levels are emitted. [https://le...og-levels)])

If preferred, you can share the host.json configuration in a private message here.

Once we review the deployed configuration, we can determine whether the observed behavior is related to the current logging policy.

Answer 1

Christos Panagiotidis 801

This is only partly expected. DEBUG being absent is normal with the default Functions configuration, but CRITICAL being downgraded to Information is not. The FunctionAppLogs schema explicitly supports Critical/LevelId 5; a host.json threshold can filter a record, but it should not change Critical into Information.

Handle the two issues separately:

To collect Python debug logs, set the app setting PYTHON_ENABLE_DEBUG_LOGGING=1 and set the relevant host.json log level to Debug or Trace. Also check whether an AzureFunctionsJobHost__logging__logLevel__... app setting overrides the deployed host.json.
The category Host.Function.Console is an important clue. Confirm the application is using Python’s built-in root logging functions inside the invocation. Remove custom StreamHandler/stdout redirection and avoid print for records whose severity must be preserved; console capture can lose the original LogRecord metadata before the host creates the FunctionAppLogs row.
After restarting, emit a minimal set of five test records and query Category, Level, LevelId, Message, HostVersion. With the supported worker path, Critical should be Level=Critical/LevelId=5.

If Critical still arrives as LevelId 2, collect the Function host version, Python version, worker version, OS/plan, host.json, and a minimal reproducer, then open an Azure support case or a python-worker issue. That would be a runtime/ingestion defect, not an intentional severity mapping.

References: Python logging in Azure Functions and the FunctionAppLogs column definitions.

Wessel Vonk 45 Reputation points

2026-07-16T07:35:44.0333333+00:00
Great - this is my host.json:

{ "version": "2.0", "logging": { "logLevel": { "default": "Debug" }, "applicationInsights": { "samplingSettings": { "isEnabled": true, "excludedTypes": "Request" } } }, "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[4.*, 5.0.0)" } }

Since I want to log things before startup (for diagnostics), I do:

if not logger.handlers: handler = logging.StreamHandler() handler.setFormatter(CustomFormatter()) logger.addHandler(handler)

That StreamHandler is probably the culprit.

The log level and level ID seem correct, but the console classifies the message as the wrong level - the colors don’t match - and in FunctionAppLogs the SeverityLevel is incorrect. Using the root logger all is well.

Is there any way to make this work with a (custom) StreamHandler?
Wessel Vonk 45 Reputation points

2026-07-16T07:36:33.4633333+00:00

See ☝️!