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 65

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 570 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 accepted by question author

Gursimran Singh 570 Microsoft External Staff Moderator

Hi @Wessel Vonk ,

Thank you for the additional information.

Based on the provided host.json, the Function App is already configured with "default": "Debug", therefore the behavior does not appear to be caused by log-level filtering.

Since the issue only occurs when logs are emitted through the custom StreamHandler, while the standard/root logger preserves the expected severity mapping, the custom console logging path appears to be the differentiating factor.

Azure Functions documentation describes the supported Python logging flow as:

Python Worker → Functions Host → Application Insights / Log Analytics.

Reference: https://learn.microsoft.com/azure/azure-functions/configure-monitoring

When the standard Functions logging pipeline is used, severity information is expected to be preserved. In your testing, this is consistent with the behavior observed when using the root logger.

At this time, we are not aware of any Microsoft-documented configuration that guarantees preservation of DEBUG and CRITICAL severity levels when logs are emitted through a custom logging.StreamHandler and ingested via the Host.Function.Console category.

Therefore, if accurate severity mapping in FunctionAppLogs is required, the recommended approach is to use the standard Azure Functions logging pipeline (root logger / Functions logging APIs) rather than a custom StreamHandler.

Gursimran Singh 570 Reputation points Microsoft External Staff Moderator

2026-07-18T15:26:32.8533333+00:00

please accept the answer if useful this we can help other users in the community

1 additional answer

Your answer

Gursimran Singh 570 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.
Gursimran Singh 570 Reputation points Microsoft External Staff Moderator

2026-07-18T15:26:32.8533333+00:00

please accept the answer if useful this we can help other users in the community

Answer 1

Christos Panagiotidis 3,551

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 65 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 65 Reputation points

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

See ☝️!

Wessel Vonk 65

Thanks, @Gursimran Singh !

Using the following approach, I was able to get it working:

def get_logger(function_name: str, level: int = logging.INFO) -> logging.Logger:
    """Create a structured logger for an Azure Function.

    Parameters
    ----------
    function_name : str
        Function name used to namespace the logger.
    level : int, default=logging.INFO
        Logging level for the returned logger.

    Returns
    -------
    logging.Logger
        Logger configured with the application context filter and root handler
        formatting.
    """

    root_logger = logging.getLogger()

    if not root_logger.hasHandlers():
        handler = logging.StreamHandler()
        root_logger.addHandler(handler)

    for handler in root_logger.handlers:
        if not isinstance(handler.formatter, CustomFormatter):
            handler.setFormatter(CustomFormatter())

    logger_name = f"sample.function_app.{function_name}"

    logger = logging.getLogger(logger_name)
    logger.setLevel(level)

    if not any(
        isinstance(current_filter, FunctionContextFilter)
        for current_filter in logger.filters
    ):
        logger.addFilter(FunctionContextFilter())

    logger.handlers.clear()
    logger.propagate = True

    return logger

This applies CustomFormatter to all (root) logger handlers, including the existing Azure Functions handlers. That works, but it feels a bit intrusive to me.

Is this considered good practice when configuring logging in Azure Functions, or is there a cleaner way to apply custom formatting without modifying every existing handler?

Gursimran Singh 570 Reputation points Microsoft External Staff Moderator

2026-07-18T15:22:51.71+00:00

Hi @Wessel Vonk ,

Thank you for sharing the solution and the additional context.

Your concern is understandable. Since the Azure Functions runtime owns and configures the root handlers, modifying the formatter of every existing handler can feel intrusive because it changes runtime-managed logging components.

From a logging perspective, allowing records to propagate to the Azure Functions root logger (logger.propagate = True) is generally the cleaner approach compared to creating a separate StreamHandler, as it keeps logs within the supported Azure Functions logging pipeline.

However, we are not aware of any Microsoft-documented mechanism that allows a custom formatter to be applied globally to Azure Functions managed handlers without interacting with those handlers directly.

Based on your testing, the approach you've implemented appears to be a reasonable workaround, but I would treat it as a customization rather than an officially documented Azure Functions logging pattern.

If your primary goal is preserving severity levels in FunctionAppLogs, then using the built-in Azure Functions logging pipeline and avoiding a custom StreamHandler remains the recommended approach.