NLog performance becomes critical the moment your application processes more than a few hundred requests per second. A synchronous file write on every _logger.LogInformation(...) call adds latency to every request -- and under load, that latency compounds across your entire request pipeline. NLog ships with two built-in wrappers designed for this: AsyncWrapper for fire-and-forget logging on a background thread, and BufferingWrapper for batching log events before flushing to a target.

This guide covers every aspect of optimizing NLog for high-throughput .NET applications. You'll learn how to configure AsyncWrapper with the right queue size and overflow strategy, when to use BufferingWrapper vs. async, how to benchmark your logging configuration with BenchmarkDotNet, and what configuration choices have the biggest impact on throughput. A production-grade configuration template ties everything together at the end.

This article assumes you already have NLog wired into your ASP.NET Core application and are familiar with targets and configuration basics. If you haven't done that yet, the setup process involves adding the NLog.Web.AspNetCore NuGet package and configuring it in Program.cs -- a process covered in the NLog getting-started material before diving into performance tuning.

Why Synchronous Logging Hurts Performance

By default, NLog writes log events synchronously on the calling thread. This means every _logger.LogWarning(...) call blocks until the write completes -- including disk I/O for file targets and network I/O for database or remote targets.

For a file target, a single synchronous write takes roughly 0.1–1 ms depending on disk speed and OS buffering. At 1,000 requests/second with 5 log events per request, that's 5,000 synchronous writes/second -- each potentially competing for the same file handle. Even with OS-level write caching, contention degrades throughput under load.

The impact is worse for remote targets:

• Database target: Each log event is an INSERT statement. At 1,000 events/second, that's 1,000 INSERT calls/second -- easily saturating a shared SQL Server instance.
• Seq/Elasticsearch targets: Each event is an HTTP POST. Latency is 5–50 ms per call, making synchronous writes completely impractical under load.

NLog's solution is target wrappers that decouple the calling thread from the I/O operation.

AsyncWrapper: The Primary Performance Tool

AsyncWrapper wraps any NLog target and moves all I/O to a dedicated background thread. The calling thread enqueues the log event in an in-memory queue and returns immediately -- the background thread drains the queue and performs the actual write.

XML Configuration

The following configuration wraps a File target inside AsyncWrapper. Notice that the File target is the inner target -- AsyncWrapper sits in front of it and manages the background queue. All configuration options on the file target remain fully functional; AsyncWrapper only changes when the write happens, not how.

<targets>
  <target xsi:type="AsyncWrapper"
          name="asyncFile"
          queueLimit="10000"
          overflowAction="Discard"
          batchSize="200"
          timeToSleepBetweenBatches="0">
    <target xsi:type="File"
            name="innerFile"
            fileName="${basedir}/logs/${shortdate}.log"
            layout="${longdate}|${level:uppercase=true}|${logger:shortName=true}|${message}${exception:format=tostring}"
            keepFileOpen="true"
            concurrentWrites="false" />  <!-- concurrentWrites removed in NLog 6; omit on NLog 6+ -->
  </target>
</targets>

JSON Configuration (appsettings.json)

The same AsyncWrapper setup expressed in appsettings.json works identically at runtime. The JSON format is preferred when your DevOps pipeline injects connection strings or log levels via environment variables -- ASP.NET Core's configuration system merges appsettings.Production.json and environment variables automatically without any code changes.

{
  "NLog": {
    "targets": {
      "asyncFile": {
        "type": "AsyncWrapper",
        "queueLimit": 10000,
        "overflowAction": "Discard",
        "batchSize": 200,
        "timeToSleepBetweenBatches": 0,
        "target": {
          "type": "File",
          "name": "innerFile",
          "fileName": "${basedir}/logs/${shortdate}.log",
          "keepFileOpen": true
          // "concurrentWrites": false  -- removed in NLog 6; omit on NLog 6+
        }
      }
    }
  }
}

Key AsyncWrapper Parameters

The default values for AsyncWrapper are conservative, chosen to be safe for single-server apps rather than optimal for high-throughput services. For production applications under serious load, each of these parameters should be reviewed and tuned against your specific traffic profile and memory constraints.

overflowAction trade-offs:

• Discard -- drops log events when the queue is full. Caller never blocks. Log events are silently lost during extreme spikes. Use for high-priority services where availability matters more than log completeness.
• Block -- caller blocks when the queue is full until space is available. No events are lost, but your request handler blocks. Useful when log completeness is a compliance requirement.
• Grow -- expands the queue without bound. Avoid in production -- unbounded memory growth during a traffic spike will cause out-of-memory errors.

async="true" Shorthand in JSON Config

In appsettings.json, adding async: true at the top of the targets section automatically wraps all targets in AsyncWrapper with default parameters. This is the zero-friction option for applications that don't need fine-grained control:

{
  "NLog": {
    "targets": {
      "async": true,
      "file": {
        "type": "File",
        "fileName": "${basedir}/logs/${shortdate}.log"
      }
    }
  }
}

This is equivalent to wrapping each target in AsyncWrapper with queueLimit=10000 and overflowAction=Discard. For tuned configurations, use explicit AsyncWrapper setup instead.

BufferingWrapper: Batch Writes for Database and Remote Targets

BufferingWrapper accumulates log events in memory and flushes them in batches when either the buffer is full or a flush interval expires. Unlike AsyncWrapper, it is synchronous by default -- the background thread sends a batch, then waits for the flush to complete before draining more events.

Use BufferingWrapper when your target benefits from batched I/O -- database targets (one INSERT per batch vs. one per event), and HTTP-based targets (one HTTP call per batch vs. per event).

<targets>
  <target xsi:type="BufferingWrapper"
          name="bufferedDb"
          bufferSize="100"
          flushTimeout="5000"
          slidingTimeout="false">
    <target xsi:type="Database"
            name="innerDb"
            dbProvider="MySql.Data.MySqlClient"
            connectionString="${environment:DB_CONNECTION_STRING}"
            commandText="INSERT INTO Logs (Timestamp, Level, Logger, Message, Exception)
                         VALUES (@time, @level, @logger, @msg, @exc)">
      <parameter name="@time" layout="${date:universalTime=true:format=o}" />
      <parameter name="@level" layout="${level:uppercase=true}" />
      <parameter name="@logger" layout="${logger:shortName=true}" />
      <parameter name="@msg" layout="${message}" />
      <parameter name="@exc" layout="${exception:format=tostring}" />
    </target>
  </target>
</targets>

The bufferSize="100" flushes when 100 events accumulate. The flushTimeout="5000" flushes any remaining events after 5 seconds even if the buffer is not full. This ensures low-traffic periods still persist log events in a timely manner.

Combining AsyncWrapper and BufferingWrapper

For maximum throughput on a database target, wrap BufferingWrapper inside AsyncWrapper:

<targets>
  <target xsi:type="AsyncWrapper" name="asyncBufferedDb" queueLimit="50000" overflowAction="Discard">
    <target xsi:type="BufferingWrapper" bufferSize="200" flushTimeout="10000">
      <target xsi:type="Database" name="db" ... />
    </target>
  </target>
</targets>

This configuration:

1. AsyncWrapper returns immediately to the caller -- no blocking
2. BufferingWrapper accumulates events in the background thread before flushing
3. Database target receives batches of 200 events per INSERT cycle

The result is dramatically fewer database round-trips compared to a synchronous per-event setup. NLog's Database target supports batching natively through this wrapper combination, making it practical for production write-heavy services.

File Target Performance Tuning

Even with AsyncWrapper moving writes off the calling thread, the file target's own configuration shapes how fast the background thread can drain the queue. Two settings in particular have a measurable impact on throughput and are frequently left at their defaults, which are not optimal for high-volume applications.

keepFileOpen

<!-- NLog 5.x: keepFileOpen + concurrentWrites="false" for single-process writers -->
<!-- NLog 6:   keepFileOpen only -- ConcurrentWrites was removed -->
<target xsi:type="File"
        fileName="${basedir}/logs/app.log"
        keepFileOpen="true"
        concurrentWrites="false" />  <!-- NLog 5.x only; omit on NLog 6+ -->

In NLog 5.x, keepFileOpen defaulted to false -- NLog opened and closed the file handle on every write. NLog 6 changed this default to true. Regardless of which version you're on, explicitly setting keepFileOpen="true" eliminates ambiguity and the repeated open/close system call overhead. This alone can double throughput on file targets.

When keepFileOpen="true" on NLog 5.x, also set concurrentWrites="false" unless multiple processes write to the same file -- the concurrent write support adds locking overhead that's unnecessary for single-process writers. Note: NLog 6 removed ConcurrentWrites from FileTarget entirely. If you're on NLog 6, omit concurrentWrites from your configuration.

Archive and Rolling Patterns

Rolling log files by date or size avoids unbounded file growth. However, the rolling check has a cost -- NLog checks the rolling condition on every write. For high-throughput applications, use archiveAboveSize with a large value (e.g., 104857600 for 100 MB) rather than hourly rolling, which minimizes the frequency of roll-over events:

<target xsi:type="File"
        fileName="${basedir}/logs/app.log"
        archiveFileName="${basedir}/logs/archive/app.{#}.log"
        archiveAboveSize="104857600"
        archiveNumbering="Rolling"
        maxArchiveFiles="10"
        keepFileOpen="true"
        concurrentWrites="false" />  <!-- NLog 5.x only; omit on NLog 6+ -->

Benchmarking NLog Configuration with BenchmarkDotNet

Before optimizing, measure. Intuitions about which configuration is fastest are often wrong -- AsyncWrapper with a full queue and Block overflow is slower than synchronous logging for small bursts.

BenchmarkDotNet is the standard tool for .NET microbenchmarks. Here's how to benchmark NLog configurations:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using Microsoft.Extensions.Logging;
using NLog;
using NLog.Extensions.Logging;

public class NLogBenchmark
{
    private Microsoft.Extensions.Logging.ILogger _syncLogger = null!;
    private Microsoft.Extensions.Logging.ILogger _asyncLogger = null!;

    [GlobalSetup]
    public void Setup()
    {
        // Synchronous file target
        var syncConfig = new NLog.Config.LoggingConfiguration();
        var syncTarget = new NLog.Targets.FileTarget("syncFile")
        {
            FileName = "${basedir}/logs/sync-bench.log",
            KeepFileOpen = true,
            ConcurrentWrites = false
        };
        syncConfig.AddRuleForAllLevels(syncTarget);
        var syncFactory = LoggerFactory.Create(b => b.AddNLog(syncConfig));
        _syncLogger = syncFactory.CreateLogger<NLogBenchmark>();

        // Async file target
        var asyncConfig = new NLog.Config.LoggingConfiguration();
        var asyncTarget = new NLog.Targets.Wrappers.AsyncTargetWrapper(
            new NLog.Targets.FileTarget("asyncFile")
            {
                FileName = "${basedir}/logs/async-bench.log",
                KeepFileOpen = true,
                ConcurrentWrites = false
            })
        {
            QueueLimit = 50000,
            OverflowAction = NLog.Targets.Wrappers.AsyncTargetWrapperOverflowAction.Discard
        };
        asyncConfig.AddRuleForAllLevels(asyncTarget);
        var asyncFactory = LoggerFactory.Create(b => b.AddNLog(asyncConfig));
        _asyncLogger = asyncFactory.CreateLogger<NLogBenchmark>();
    }

    [Benchmark(Baseline = true)]
    public void SynchronousFileLogging()
    {
        _syncLogger.LogInformation("Order {OrderId} processed in {ElapsedMs}ms", 12345, 42);
    }

    [Benchmark]
    public void AsyncWrapperLogging()
    {
        _asyncLogger.LogInformation("Order {OrderId} processed in {ElapsedMs}ms", 12345, 42);
    }
}

class Program
{
    static void Main() => BenchmarkRunner.Run<NLogBenchmark>();
}

When running these benchmarks, AsyncWrapper often measures faster per call in microbenchmarks for file targets because the caller only enqueues the event -- the actual I/O happens on the background thread and is not measured in the per-call number. End-to-end throughput depends on I/O speed, queue depth, and background thread scheduling, so always validate under realistic concurrent load. For comprehensive BenchmarkDotNet usage, the guide at How to Use BenchmarkDotNet covers the key options.

Avoiding async void Anti-Patterns in Custom Targets

If you write a custom NLog target that does async I/O (e.g., posting to a webhook), it's tempting to make Write async. Avoid this:

// ❌ Dangerous -- async void, exceptions are unobserved
protected override async void Write(LogEventInfo logEvent)
{
    await _httpClient.PostAsync(_webhookUrl, BuildContent(logEvent));
}

NLog's Write method is synchronous by design. async void methods fire and forget with no way to track completion or catch exceptions -- a failing HTTP call silently kills the method. The async void pattern is discussed in detail at Async Void Methods in C#: The Dangers.

Instead, use Task.Run to fire the work onto a thread pool thread, or override WriteAsyncTask which is the correct async extension point in NLog:

// ✅ Correct async target extension point
protected override async Task WriteAsyncTask(LogEventInfo logEvent, CancellationToken cancellationToken)
{
    await _httpClient.PostAsync(_webhookUrl, BuildContent(logEvent), cancellationToken);
}

When overriding WriteAsyncTask, NLog manages the async scheduling. Wrap the call in AsyncWrapper and NLog coordinates flushing correctly on application shutdown.

AOT and Source Generation Considerations

NLog 6 supports Native AOT with some limitations. AsyncWrapper and BufferingWrapper are both AOT-compatible in NLog 6. However, your app still needs to avoid reflection-heavy config and extension loading without explicit trimming hints -- AOT compatibility covers the wrappers themselves, not arbitrary reflection-based target scanning. If you register NLog targets or extensions viareflection scanning (e.g., using Scrutor or a similar library), prefer explicit registration or a source-generator approach when publishing with trimming enabled. The Automatic Dependency Injection in C# with Needlr guide covers source-generation-based registration that is AOT-safe -- the same principles apply when you need to register custom NLog target types at startup without reflection.

Production Performance Template

Here is a complete, ready-to-use high-throughput NLog configuration for an ASP.NET Core application. It combines all the techniques covered above -- async wrappers per target, buffering on the structured JSON target, file tuning, and production-grade rules that silence framework noise while preserving full application output.

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      autoReload="true">

  <targets>
    <!-- Async console target (dev-friendly, low overhead) -->
    <target xsi:type="AsyncWrapper"
            name="asyncConsole"
            queueLimit="10000"
            overflowAction="Discard">
      <target xsi:type="ColoredConsole"
              name="console"
              layout="${time}|${level:uppercase=true:padding=-5}|${logger:shortName=true}|${message}${exception:format=message}" />
    </target>

    <!-- Async rolling file target (high throughput) -->
    <target xsi:type="AsyncWrapper"
            name="asyncFile"
            queueLimit="50000"
            overflowAction="Discard"
            batchSize="500"
            timeToSleepBetweenBatches="0">
      <target xsi:type="File"
              name="file"
              fileName="${basedir}/logs/${shortdate}.log"
              archiveFileName="${basedir}/logs/archive/app.{#}.log"
              archiveAboveSize="104857600"
              archiveNumbering="Rolling"
              maxArchiveFiles="10"
              keepFileOpen="true"
              concurrentWrites="false"  <!-- NLog 5.x only; omit on NLog 6+ -->
              layout="${longdate}|${level:uppercase=true}|${mdlc:CorrelationId}|${logger:shortName=true}|${message}${exception:format=tostring}" />
    </target>

    <!-- Async buffered structured JSON target (for log aggregation) -->
    <target xsi:type="AsyncWrapper"
            name="asyncJson"
            queueLimit="100000"
            overflowAction="Discard">
      <target xsi:type="BufferingWrapper"
              name="bufferedJson"
              bufferSize="500"
              flushTimeout="5000">
        <target xsi:type="File"
                name="jsonFile"
                fileName="${basedir}/logs/structured-${shortdate}.json"
                keepFileOpen="true"
                concurrentWrites="false">  <!-- NLog 5.x only; omit on NLog 6+ -->
          <layout xsi:type="JsonLayout" includeAllProperties="true" excludeEmptyProperties="true">
            <attribute name="timestamp" layout="${date:universalTime=true:format=o}" />
            <attribute name="level" layout="${level:uppercase=true}" />
            <attribute name="logger" layout="${logger:shortName=true}" />
            <attribute name="correlationId" layout="${mdlc:CorrelationId}" />
            <attribute name="message" layout="${message}" />
            <attribute name="exception" layout="${exception:format=tostring}" />
          </layout>
        </target>
      </target>
    </target>
  </targets>

  <rules>
    <!-- Suppress EF Core query logging -->
    <logger name="Microsoft.EntityFrameworkCore.Database.Command" maxlevel="Info" final="true" />
    <!-- Suppress all Microsoft.*/System.* Debug/Info -->
    <logger name="Microsoft.*" maxlevel="Info" final="true" />
    <logger name="System.*" maxlevel="Info" final="true" />
    <!-- Framework warnings → file only -->
    <logger name="Microsoft.*" minlevel="Warn" writeTo="asyncFile" final="true" />
    <!-- Application → all targets -->
    <logger name="*" minlevel="Debug" writeTo="asyncConsole,asyncFile,asyncJson" />
  </rules>
</nlog>

This configuration provides:

• Non-blocking async for all three targets
• 500-event batching on the JSON target to reduce flush frequency
• Independent queue limits per target (console queue is smaller since console is fast)
• Production rules that silence framework noise while preserving all application output

Frequently Asked Questions

What is the difference between AsyncWrapper and async="true" in NLog?

async="true" in appsettings.json automatically wraps every target in AsyncWrapper with default parameters (queueLimit=10000, overflowAction=Discard). An explicit AsyncWrapper lets you tune queueLimit, overflowAction, batchSize, and timeToSleepBetweenBatches per target. Use async="true" for quick setups and explicit AsyncWrapper when you need fine-grained throughput control for specific targets.

What should I set queueLimit to in NLog AsyncWrapper?

A reasonable starting point is 10,000–50,000 events. The right value depends on your burst traffic profile and available memory. At 200 bytes per event (approximate average), a 50,000-event queue uses about 10 MB. Monitor your queue utilization under load using NLog's internal logging (internalLogLevel="Warn") to see if events are being discarded. If they are, increase queueLimit or reduce event volume at the source.

Does AsyncWrapper prevent log events from being lost on application shutdown?

AsyncWrapper flushes its queue on shutdown via NLog.LogManager.Shutdown(). If you use NLog.Web.AspNetCore, the flush is called automatically when the host shuts down. If you wire NLog manually, call LogManager.Shutdown() in IHostApplicationLifetime.ApplicationStopped to ensure queued events are written before the process exits.

When should I use BufferingWrapper instead of AsyncWrapper?

Use BufferingWrapper when your target benefits from batch I/O -- most commonly database targets and HTTP-based targets. A single INSERT with 100 rows is much faster than 100 separate INSERTs. AsyncWrapper makes the caller non-blocking; BufferingWrapper reduces I/O round-trips. Use both together for the best of both: non-blocking caller plus batched writes.

Does keepFileOpen="true" break log rotation on Linux?

On Linux, a file with an open handle can still be deleted (the inode remains until all handles are released). Log rotation tools like logrotate use the copytruncate option to work with applications that keep files open. NLog also supports autoFlush="true" and the ArchiveOldFileOnStartup option. For containerized deployments, write to stdout and let the container runtime handle log collection -- which sidesteps file rotation entirely.

How do I measure the actual throughput of my NLog configuration?

Use BenchmarkDotNet with realistic message payloads and real targets (not null targets), and measure under concurrent load that matches your production request pattern. Single-threaded benchmarks underestimate contention on the file handle or queue. Test with multiple concurrent Task instances calling the logger to simulate real-world producer/consumer load on the AsyncWrapper queue.

Wrapping Up

NLog performance optimization comes down to three principles: move I/O off the calling thread with AsyncWrapper, reduce I/O round-trips with BufferingWrapper, and configure file targets to keep files open. Most applications can achieve sub-microsecond per-call logging latency with these tools properly configured.

The key takeaways:

• AsyncWrapper is the first and most important optimization -- it turns every logging call from a blocking I/O operation into an in-memory queue enqueue
• Tune queueLimit and overflowAction per target based on the target's write speed and your tolerance for dropped events
• Combine AsyncWrapper + BufferingWrapper for database and HTTP targets to batch I/O and reduce network round-trips
• keepFileOpen="true" is free throughput for single-process file targets; on NLog 5.x, pair with concurrentWrites="false" (NLog 6 removed ConcurrentWrites from FileTarget)
• Benchmark with BenchmarkDotNet under realistic concurrent load before and after changes

Once you've optimized NLog for throughput, the next architectural question is often whether NLog is the right choice for your project. NLog and Serilog have different strengths -- NLog's rules-based routing is more powerful for complex multi-target scenarios, while Serilog's sink ecosystem is broader and its C# fluent API is more natural for teams that prefer code-first configuration.

NLog rules and filters give you surgical control over which log events reach which targets and under what conditions. Most developers know how to set a minimum log level, but NLog's rule engine goes much further -- you can route logs by logger name pattern, suppress entire namespaces, send warning-and-above to a separate file, or write only specific business events to a database while everything else goes to the console.

This guide covers every dimension of NLog's rules and filters system with practical C# examples. By the end, you'll understand how to silence the Microsoft.* noise that clutters development logs, how final="true" stops rule evaluation early, how to use when filter conditions for fine-grained control, and how to design a multi-target routing strategy for a production ASP.NET Core application.

If you're new to NLog, start with package installation and basic configuration before working through the routing system -- getting a working logger first makes the rules examples below much easier to experiment with. The complete guide to logging in .NET provides foundational context on how NLog fits into the broader .NET logging ecosystem alongside Serilog and Microsoft.Extensions.Logging.

How NLog Rules Work

The <rules> section in NLog configuration defines a pipeline. NLog evaluates rules top-to-bottom for every log event. Each rule can match by logger name, level, or both, and directs matching events to one or more targets. Rules keep evaluating until a final="true" rule matches -- at that point, evaluation stops for that log event.

<rules>
  <!-- Rule 1: Microsoft.* logs at Warn+ go to file -->
  <logger name="Microsoft.*" minlevel="Warn" writeTo="file" final="true" />
  <!-- Rule 2: Everything at Debug+ goes to console -->
  <logger name="*" minlevel="Debug" writeTo="console" />
</rules>

This configuration:

1. Sends Microsoft.* events at Warn or above to the file target, then stops (no console)
2. Sends everything else at Debug or above to console

Without final="true" on the first rule, Microsoft.* Warn events would also hit the console.

Rules Are Ordered and Cumulative

Rules are not exclusive by default -- a single log event can match multiple rules and be sent to multiple targets. This is intentional: NLog lets you fan out the same event to a console target, a file target, and a database target simultaneously by having multiple non-final rules match it.

The order matters because final="true" stops evaluation. Place more specific rules (with name patterns or level ranges) before more general ones.

Logger Name Matching

The name attribute on a rule supports glob-style patterns:

The logger name is the category name passed to ILogger<T>. For ILogger<HomeController>, the logger name is the fully qualified type name: MyApp.Controllers.HomeController.

Namespaced Routing Example

Here is a realistic routing setup for a production ASP.NET Core application that routes application logs, framework logs, and security audit logs to separate destinations:

<rules>
  <!-- Audit logs: SecurityAudit category → dedicated file, stop here -->
  <logger name="SecurityAudit" minlevel="Info" writeTo="auditFile" final="true" />

  <!-- Framework noise: Debug/Info Microsoft.* and System.* → discard -->
  <logger name="Microsoft.*" maxlevel="Info" final="true" />
  <logger name="System.*" maxlevel="Info" final="true" />

  <!-- Framework warnings: Warn+ from Microsoft.* → general file only, stop here -->
  <logger name="Microsoft.*" minlevel="Warn" writeTo="file" final="true" />

  <!-- Application logs: everything at Debug+ → console and rolling file -->
  <logger name="*" minlevel="Debug" writeTo="console,file" />
</rules>

The maxlevel="Info" rule with no writeTo and final="true" is the standard idiom for silencing a namespace entirely at a given level range. Because it has no target, the events are discarded. The final="true" prevents them from falling through to the catch-all rule at the bottom.

Log Level Ranges

NLog rules support minlevel, maxlevel, level, and levels attributes for precise level control. Understanding the difference between these is important -- minlevel is the most commonly used and matches the specified level and everything above it, while maxlevel caps at the specified level and includes everything below it. You can combine both to target a specific range.

NLog's levels in ascending order: Trace → Debug → Info → Warn → Error → Fatal.

Level-Based Fan-Out

A common pattern sends high-severity events to a real-time alerting target while all events go to persistent storage:

<rules>
  <!-- Critical errors → Slack/PagerDuty webhook -->
  <logger name="*" minlevel="Error" writeTo="alertWebhook" />
  <!-- Everything Info+ → rolling file (separate from above, both fire) -->
  <logger name="*" minlevel="Info" writeTo="rollingFile" />
  <!-- Debug+ → console (dev only, disabled in prod via config) -->
  <logger name="*" minlevel="Debug" writeTo="console" />
</rules>

Because none of these rules use final="true", an Error event matches all three rules and is sent to all three targets simultaneously. This is the intended behavior -- you want errors in both the alert webhook and the rolling file.

The final Attribute

final="true" stops NLog from evaluating further rules for the current log event once this rule matches. It is the single most important tool for preventing log duplication and implementing "route-and-stop" logic.

Without final, every non-final rule that matches a log event will process it. With final, NLog stops at the first matching rule with final="true".

Silencing Microsoft Internals

The most common use of final is suppressing ASP.NET Core's verbose internal logging:

<rules>
  <!-- Suppress Microsoft.* Debug and Info entirely -->
  <logger name="Microsoft.*" maxlevel="Info" final="true" />
  <!-- Suppress System.* Debug and Info entirely -->
  <logger name="System.*" maxlevel="Info" final="true" />
  <!-- Everything else at Debug+ → console and file -->
  <logger name="*" minlevel="Debug" writeTo="console,file" />
</rules>

Notice the rules have no writeTo attribute -- they match and terminate without writing anywhere. This is how you discard log events in NLog. The final="true" then prevents the discarded events from reaching the catch-all rule below.

Route-and-Stop Pattern

Use final when a category of logs has special handling and must not also flow through general routing. Without final, the event would continue matching subsequent rules and end up in targets that were not intended for that category -- leading to duplicate log entries or cluttered outputs.

<rules>
  <!-- Performance metrics → metrics target only, stop here -->
  <logger name="Performance.*" minlevel="Info" writeTo="metricsTarget" final="true" />
  <!-- Background job logs → background jobs file only, stop here -->
  <logger name="*.BackgroundJob" minlevel="Debug" writeTo="backgroundFile" final="true" />
  <!-- General application → default targets -->
  <logger name="*" minlevel="Info" writeTo="console,file" />
</rules>

Each specialized category is handled in isolation. The catch-all at the bottom never sees Performance or BackgroundJob log events.

Filter Conditions with when

The when filter provides fine-grained, expression-based filtering within a rule. While name and level attributes filter on the rule level, when filters on a per-event basis using NLog's condition language.

<rules>
  <logger name="*" minlevel="Debug" writeTo="file">
    <filters>
      <!-- Skip health check endpoint noise -->
      <when condition="contains('${aspnet-request-url}', '/health')" action="Ignore" />
    </filters>
  </logger>
</rules>

The action attribute controls what happens when the condition is true:

Condition Language Basics

NLog's condition language is a mini expression language built into the logging library -- no external dependencies required. It supports comparisons, string operations, and boolean logic, and can reference any built-in renderer value including request URL, message content, and log level. The following expressions illustrate common patterns you can use:

level == LogLevel.Error
level >= LogLevel.Warn
message contains 'payment'
logger starts-with 'MyApp.Services'
contains('${aspnet-request-url}', '/healthz')
length(message) > 500

Conditions can be combined with and, or, not:

<when condition="level >= LogLevel.Warn and contains(logger, 'Database')"
      action="LogFinal" />

Practical Filter Example: Deduplication

In a high-throughput service, the same error can fire thousands of times per second. Use a when filter with a custom property to limit repetition. The ThrottleKey property must be set on the log event scope -- use NLog.ScopeContext.PushProperty to attach it before logging:

// Set ThrottleKey on the ambient scope so the filter condition can read it
using (NLog.ScopeContext.PushProperty("ThrottleKey", "payment-timeout"))
{
    _logger.LogError("Payment gateway timeout for {OrderId}", orderId);
}

<rules>
  <logger name="*" minlevel="Warn" writeTo="alertFile">
    <filters defaultAction="Log">
      <!-- Only log events that have ThrottleKey set (i.e., are throttle-eligible) -->
      <when condition="${event-properties:item=ThrottleKey} == ''"
            action="Log" />
    </filters>
  </logger>
</rules>

This pattern is a starting point -- NLog's WhenRepeatedFilter (available as a NuGet extension) provides a more complete implementation with built-in time-based deduplication.

JSON Configuration (appsettings.json)

Everything above can be expressed in appsettings.json for ASP.NET Core applications. The JSON format is more CI/CD-friendly since DevOps teams can inject values via environment variables without touching XML files.

{
  "NLog": {
    "rules": [
      {
        "logger": "Microsoft.*",
        "maxlevel": "Info",
        "final": true
      },
      {
        "logger": "System.*",
        "maxlevel": "Info",
        "final": true
      },
      {
        "logger": "Microsoft.*",
        "minlevel": "Warn",
        "writeTo": "file",
        "final": true
      },
      {
        "logger": "*",
        "minlevel": "Debug",
        "writeTo": "console,file"
      }
    ]
  }
}

The final property in JSON corresponds to final="true" in XML. The behavior is identical -- NLog evaluates JSON and XML configurations the same way at runtime.

Environment-Specific Rules

A real production setup often needs different rules for development vs. production environments. Development teams want verbose output with Trace and Debug enabled for fast feedback, while production should be quiet and efficient -- logging Info and above from application code, and suppressing framework Debug/Info entirely to reduce storage costs and improve signal quality. There are two main approaches to managing environment-specific rules.

Approach 1: Environment Variables in Config

Important: minlevel in NLog rules is not a layout -- it expects a literal level value (Trace, Debug, Info, Warn, Error, Fatal). NLog does not evaluate layout renderers or ternary expressions in minlevel. A config like minlevel="${environment:...}=Development ? Trace : Info" is invalid and will be rejected or silently ignored at runtime.

If you need environment-conditional minimum levels in a single config file, use NLog's <variable> support with ${gdc:item=...} or set a NLog global diagnostic context value from Program.cs before loading configuration. In practice, Approach 2 (separate config files) is simpler and less error-prone.

Approach 2: Separate Config Files

The simpler and more maintainable approach is a separate nlog.Production.config with tighter rules, loaded by your deployment pipeline. During development, nlog.Development.config uses minlevel="Debug" everywhere. In production, nlog.Production.config uses minlevel="Info" for application code and suppresses all Microsoft.* Debug/Info. This avoids complex condition expressions and makes each environment's routing obvious.

// In Program.cs, resolve config file by environment
var env = builder.Environment.EnvironmentName;
var configFile = $"nlog.{env}.config";
if (!File.Exists(configFile)) configFile = "nlog.config"; // fallback

LogManager.Setup().LoadConfigurationFromFile(configFile);

Complete Production Rules Template

Here is a complete rules configuration for a production ASP.NET Core application with console, rolling file, and error-only alert targets:

<rules>
  <!-- 1. Suppress EF Core query spam (Debug/Info) -->
  <logger name="Microsoft.EntityFrameworkCore.Database.Command"
          maxlevel="Info" final="true" />

  <!-- 2. Suppress all Microsoft.*/System.* Debug and Info -->
  <logger name="Microsoft.*" maxlevel="Info" final="true" />
  <logger name="System.*" maxlevel="Info" final="true" />

  <!-- 3. Microsoft.* Warn+ → file only (no console) -->
  <logger name="Microsoft.*" minlevel="Warn" writeTo="file" final="true" />
  <logger name="System.*" minlevel="Warn" writeTo="file" final="true" />

  <!-- 4. Application errors → dedicated error file (in addition to rules below) -->
  <logger name="MyApp.*" minlevel="Error" writeTo="errorFile" />

  <!-- 5. All application logs → console + rolling file -->
  <logger name="*" minlevel="Info" writeTo="console,file" />
</rules>

This layered approach eliminates framework noise from the console, keeps framework warnings in the file for postmortem analysis, and maintains a separate error file for fast filtering during incidents. NLog's target system -- file, console, database, Seq, and others -- is what backs the writeTo attribute in each rule.

Frequently Asked Questions

What does final="true" do in NLog rules?

final="true" stops NLog from evaluating further rules for the current log event once the rule with final matches. Without it, NLog continues evaluating all remaining rules and sends the event to any additional matching targets. Use final when you want route-and-stop behavior -- the event is handled by exactly one rule and goes no further.

How do I silence Microsoft.* logs without affecting my application logs?

Add two rules before your catch-all: one that matches Microsoft.* with maxlevel="Info" and final="true" (no writeTo -- this discards Debug/Info silently), and one that matches Microsoft.* with minlevel="Warn" and routes to a file target with final="true". This sends framework warnings to file without showing them on the console, and completely drops Debug/Info noise.

Can a single log event match multiple NLog rules?

Yes -- by default, NLog evaluates all rules top-to-bottom and a single event can match and be written by multiple rules simultaneously. This is how you fan out to multiple targets. The only exception is when a matching rule has final="true", which stops evaluation after that rule.

What is the difference between level and minlevel in NLog rules?

level matches exactly one log level (e.g., level="Error" matches only Error, not Fatal). minlevel matches that level and all higher levels (e.g., minlevel="Warn" matches Warn, Error, and Fatal). maxlevel matches that level and all lower levels. Use levels="Error,Fatal" when you need a non-contiguous set.

How do I use when filters to ignore health check log events?

Add a <filters> block inside the rule and use a when condition that matches the URL or message content. For ASP.NET Core health checks, contains('${aspnet-request-url}', '/health') with action="Ignore" drops events from health check endpoints before they are written to any target. Install NLog.Web.AspNetCore to enable the aspnet-request-url renderer.

How do I route logs to different files by log level?

Use multiple non-final rules, each with writeTo pointing to a different target, and level constraints that don't overlap. For example: a rule with minlevel="Error" and writeTo="errorFile", and a separate rule with minlevel="Info" maxlevel="Warn" and writeTo="infoFile". Since neither rule uses final, Error events match the first rule only (because Errors are above maxlevel=Warn), while Warn and Info events match only the second rule.

Should I configure NLog rules in XML or JSON?

Both are functionally equivalent. Use JSON (appsettings.json) for ASP.NET Core applications where you want environment-specific overrides via appsettings.Production.json or environment variables. Use XML (nlog.config) when your operations team is more comfortable with it or when you need NLog-specific features like dynamic reloading via autoReload="true". In ASP.NET Core specifically, integrating NLog rules with the host's middleware pipeline -- for instance, to enrich log context per-request -- works cleanly alongside custom middleware.

Wrapping Up

NLog's rules and filters system is one of its biggest strengths over simpler logging libraries. The combination of glob name matching, level ranges, final="true" short-circuits, and expression-based when filters lets you implement arbitrarily complex routing logic without any C# code -- just configuration.

The key patterns to internalize:

• Silence by namespace: name="Microsoft.*" maxlevel="Info" final="true" (no writeTo)
• Route and stop: match a category, send it to a target, add final="true"
• Fan-out: multiple non-final rules all matching name="*" send to multiple targets simultaneously
• Condition filtering: when conditions inside rules for per-event decisions

Complex rule chains have measurable performance implications -- especially when rules fan out to multiple slow targets synchronously. Wrapping synchronous targets in an AsyncWrapper and benchmarking with BenchmarkDotNet are the key techniques for keeping NLog from becoming a throughput bottleneck in high-traffic applications. For comparison on how Serilog approaches similar routing decisions, the Serilog in .NET complete guide covers the equivalent sink and filter configuration patterns.

• Senior is a successful career destination
• Higher levels require broader organizational scope
• Career progression is not a straight line
• Join me for the live stream (or watch the recording) on Monday, August 10 at 7:00 PM Pacific!

What Comes After Senior Software Engineer?

Have you ever looked at a software engineering career ladder and wondered why everything seems to move reasonably well until senior, and then suddenly the next step feels like a wall?

You're not imagining that shift.

I have talked before about why engineers can feel stuck at senior, but I want to approach this from a slightly different angle. Sometimes the friction is about your growth, your manager, or unclear expectations. But sometimes the ladder itself genuinely changes shape after senior.

That does not mean you failed. It does not mean your company wants to hold you back. And despite how easy it is to blame every weird career problem on AI right now, I do not think AI created this one.

So what is actually going on?

You can check out my full thoughts on this in the video below:

The Ladder Changes Shape After Senior

The first complication is that software engineering titles are wildly inconsistent.

Junior, mid-level, and senior are common concepts, even if a company calls them Software Engineer I, Software Engineer II, SDE, SWE, or something else. Beyond senior? Things get messy fast.

One company might have staff, principal, senior principal, distinguished, fellow, or partner roles. Another company might skip staff entirely. A smaller company might have nothing beyond senior on the individual contributor track.

That was my experience before Microsoft. For most of my eight years there, the technical path was basically developer and senior developer. There was an architect role that never felt fully defined. Even as a technical manager, I eventually reached a point where there was no clearly established next role on that track.

Was I suddenly incapable of growing? Of course not. The organization simply had not created an endless sequence of titles.

That distinction matters. We often treat a career ladder like a universal map, but it is really a model of what one organization needs.

Title Inflation Makes The Wall Feel Worse

I want to be careful here because I do not have data to prove this. Treat it as an observation from roughly fifteen years in the industry, not a measured fact.

I suspect the expected time between early-career promotions has compressed. Companies use titles as recruiting tools. Employees move between organizations more often. Managers feel pressure to show progression. People understandably compare their timelines with everyone announcing promotions online.

The result is an expectation that every step should arrive on roughly the same schedule -- or at least that there should be very concrete steps in a prescribed amount of time to get there.

But careers are not linear. Going from level one to level two in a year does not mean every future level should take one more year. Follow that math far enough and everyone becomes a CTO before the end of the decade. Clearly, that is not how organizations work.

The higher you go, the larger the expected scope usually becomes. There are fewer roles with that scope, fewer opportunities to demonstrate it, and fewer people the organization actually needs operating there.

That curve was always going to get steeper. Title inflation just makes the change feel more abrupt.

Senior Can Be The Destination

The phrase people often use is terminal level. I don't love it. It sounds dark, like your career has arrived at a dead end.

That's not what it means.

A terminal level is a stable point where someone can perform successfully for the rest of their career. For many software engineering organizations, that point is somewhere in the senior band.

Think about what that says about you. You are trusted to solve difficult problems. You can deliver high-quality work consistently. Teams depend on you. You can guide other engineers, handle ambiguity, and operate without someone spelling out every step.

That is a successful career.

It can also be a demanding one. I have written about how senior engineers often spend less time coding because their impact increasingly includes design, mentoring, coordination, and helping others move faster. Staying at senior does not mean staying static.

Your skills can deepen. Your influence can grow. Your compensation can improve. You can take on new domains and become the person everyone relies on without collecting another title every eighteen months.

Compensation And Promotion Are Related, Not Identical

This is usually where someone asks: "Okay, but what happens to my compensation if I am not getting promoted?"

Fair question.

The exact answer depends on the company, but promotion should not be the only mechanism for recognizing strong performance. Salary growth, bonuses, stock, expanded ownership, and other rewards can continue while you remain in the same level.

A promotion usually comes with a larger adjustment because the expectations changed. But that does not mean every strong review must end with a new title.

You can be performing extremely well at senior, receive above-target rewards, and still not be operating at the next level. Those signals overlap, but they are not identical.

That can actually be a healthy balance. Maybe you are kicking ass at senior, being paid fairly, doing meaningful work, and preserving room for your family or everything else outside work. There is nothing lesser about that choice.

Organizations Cannot Be Made Entirely Of Principal Engineers

Now we get to the structural part.

Imagine an organization where every engineer is principal, staff, distinguished, or whatever the top levels are called. It sounds amazing if you picture a video game team where everyone has max stats. If you could build an NBA 2K team of max-stat players, or your RPG party was all max level, that's what you'd want -- right?

In practice, what work are all of those people doing?

The next level after senior usually expects broader impact across teams, products, or an organization. If you are actively targeting that path, I have a separate breakdown of what principal-level scope actually looks like. The important point here is that cross-organization work is not infinite -- at least not infinitely done in parallel with all the other cross-organization work.

A company needs people setting technical direction across teams. It also needs many more people turning that direction into reliable products, systems, and customer outcomes.

You do not need hundreds of engineers independently trying to lead company-wide initiatives. At some point, everyone collides with everyone else.

This is not an argument for gatekeeping. It is an explanation of why the number of roles naturally narrows. The organization needs a different distribution of scope at each level.

Healthy Teams Need A Spread Of Experience

The same idea applies within a team.

You do not want a team made entirely of brand-new engineers because the coaching and operational overhead would overwhelm the few experienced people supporting them. But stacking a team entirely with the highest-level engineers does not make sense either.

A healthy team usually has a spread:

• Junior engineers building fundamentals and taking on well-scoped work
• Mid-level engineers carrying a large share of independent delivery
• Senior engineers handling complex work, mentoring, and creating leverage
• A smaller number of staff or principal engineers working across broader boundaries

That spread creates continuity. Junior engineers learn from people with more experience. Senior engineers develop coaching and delegation skills. The organization builds its next generation instead of hoping experienced hires appear forever.

This is where AI enters the conversation, but not as the cause of the senior-level wall. Companies deciding they no longer need junior engineers because AI can replace them are creating a different problem. I have shared my concerns about junior developers relying on AI without building fundamentals, and cutting off the junior pipeline removes mentoring opportunities and future senior talent too.

The whole system needs continuity. You cannot keep only the top of the pyramid and expect it to replenish itself.

What To Do When You Feel Stuck

Understanding the structure does not make vague promotion feedback any less frustrating.

If your manager keeps telling you, "Maybe next time," while you spend another review cycle trying to prove yourself, you need more than encouragement. You need clarity.

Actionable Tip: ask questions that separate your performance from the organization's available opportunities:

1. What specific evidence is missing? Ask for observable examples, not "more impact."
2. Am I consistently operating at the next level? A strong year at your current level is not automatically the same thing.
3. Does this team have work with the required scope? You cannot demonstrate cross-team leadership if every meaningful decision is already owned elsewhere.
4. Is a role realistically available? Sometimes the organizational shape creates more back pressure than anyone wants to say directly.
5. What would make the next review materially different? If nobody can answer, that is useful information.

You may discover that you have real gaps to close. Great. Now you can work on something concrete.

You may discover that you are ready, but the organization has no room. That does not automatically mean you should leave, but it gives you an honest tradeoff to consider. An internal move or another company may offer the scope that your current team cannot.

And please protect your energy. There is a difference between stretching into bigger responsibility and running yourself into the ground chasing a label. My advice on pursuing promotions without burning yourself out still applies here.

Your Title Is Not Your Entire Career

I understand why titles matter. They affect compensation, opportunity, how recruiters find you, and how many of us measure whether we are moving forward.

But the ladder cannot be the only scoreboard.

Senior software engineer is not a waiting room where you sit until your real career begins. It is a high-skill, high-trust role that many people work very hard to reach. If you stay there and continue doing excellent work, that is not failure.

If you want principal, staff, management, or another path, go after it with clear eyes. Learn what the role actually requires. Find out whether your organization has the right opportunities. Build the evidence. Decide whether the tradeoffs fit the life you want.

Don't let the absence of another title erase everything you have already accomplished.

Careers are not straight lines. Organizations are not infinite ladders. And success is much bigger than the word printed beside your name.

• Join me and other software engineers in the private Discord community!
• Resume reviews and interview guidance!
• Software engineering podcast and livestreams!
• My Code Commute vlogs are on YouTube!
• All of my weekly vlogs are on YouTube!
• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.

​Nick "Dev Leader" Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

Like what you read or watched from the recap? I'd love if you helped share on Reddit or Daily.dev so others can see!

Weekly Recap

I'm Sick Of Helping My Incompetent Engineering Peer

From the ExperiencedDevs subreddit, this developer wanted perspectives on working with a colleague that seems incompetent.

What The HECK Comes After Senior Software Engineer?

From the ExperiencedDevs subreddit, this developer wanted perspectives on progressing beyond senior software engineer.

NLog Layout Renderers and Structured Logging in C#

Master NLog layout renderers and structured logging in C#. Learn how to use JsonLayout, message templates, MDC correlation IDs, and custom layout renderers with real .NET examples.

NLog Targets in .NET: File, Database, Console, and Custom

Deep dive into NLog targets in .NET. Learn how to configure File, Console, Database, Seq, and custom targets with real C# examples for ASP.NET Core and Worker Services.

Getting Started with NLog in ASP.NET Core

Learn how to set up NLog in ASP.NET Core step by step. Covers XML nlog.config and appsettings.json configuration, Program.cs setup, Worker Services, and ILogger usage.

NLog in .NET: Complete Guide to Flexible Logging

Master NLog in .NET with this complete guide. Learn targets, rules, layout renderers, structured logging, and performance optimization for C# applications.

Distributed Tracing Across .NET Services with OpenTelemetry: W3C Trace Context and Baggage

Learn distributed tracing in .NET with OpenTelemetry: W3C trace context, Baggage, and traceparent headers linking spans across services, with C# examples.

• Join me and other software engineers in the private Discord community!
• Resume reviews and interview guidance!
• Software engineering podcast and livestreams!
• My Code Commute vlogs are on YouTube!
• All of my weekly vlogs are on YouTube!
• Remember to check out my courses, including this awesome discounted bundle for C# developers: