Request-scoped minimum-level override using the existing logging pipeline

Problem

Production applications commonly use a Warning minimum level to control log volume and cost. During live investigation, it may be necessary to capture detailed Debug events for one specific asynchronous operation without increasing logging globally. A global LoggingLevelSwitch affects every concurrent operation. Namespace-based minimum-level overrides are also too broad. Sink-level filtering cannot solve this problem because events rejected by the logger’s root minimum level are never created and therefore never reach a sink.

Desired behaviour

Allow an application to temporarily lower the effective minimum level for the current asynchronous execution context.

Conceptually:

using (LogContext.PushMinimumLevel(LogEventLevel.Debug)) { await operation(); }

The exact API is only illustrative.

Expected behaviour:

Debug events are enabled only within the selected logical execution context. Concurrent operations remain at the normal Warning minimum level. The override flows safely through asynchronous calls. Events use the existing sinks, enrichers, formatting, and configuration. Each event is emitted only once. Disposing the scope reliably restores the normal minimum level. Nested scopes restore the preceding level correctly. Parallel execution contexts do not affect one another.

Current limitation

The available minimum-level controls are global or based on source context. Creating a separately configured logger can capture events below the main logger’s minimum level, but this duplicates configuration and introduces additional logger and sink lifecycle concerns. It may also cause duplicate events or separate output destinations.

Questions

Would an execution-context-scoped minimum-level override be suitable for Serilog core?

If not, is there an existing extension point through which this can be implemented while reusing the current logging pipeline?

Are there concurrency, performance, or architectural constraints that would make this unsuitable?

Would a different API or abstraction fit Serilog’s architecture better?

Environment

Serilog: 4.3.0 Serilog.AspNetCore: 10.0.0 Target framework: .NET 10