Noisy ImageSharp Logs in Umbraco

If you've ever popped into the log viewer in your Umbraco backoffice only to be told "Today's log file is too large to be viewed", there's a very good chance ImageSharp is the one filling your logs up.

This is a quick post on why it happens, the log viewer limit you've probably just hit, and the one-line config change that fixes it.

Umbraco uses ImageSharp.Web to handle image resizing, format conversion, and caching. Useful stuff. But by default, its middleware logs every single image request at Information level. You'll see entries like this stacking up in your logs:

{
  "@t": "2026-03-29T23:26:23.3574158Z",
  "@mt": "Sending image. Request uri: '{Uri}'. Cached Key: '{Key}'",
  "Uri": "https://www.example.com/media/xxkp1tgh/logo.png?height=80&format=webp",
  "Key": "29531e7ee102",
  "SourceContext": "SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware",
  "Log4NetLevel": "INFO "
}

One of those for every image, every request. On a content-heavy site with a few dozen images per page and any kind of traffic, you can easily generate hundreds of MB of log data a day - all of it noise.

Umbraco's built-in log viewer has a hard-coded cap of 100 MB per log file. If a day's log goes over that, the backoffice will refuse to open it and show the "too large to be viewed" message instead.

You can see it for yourself in the Umbraco source. On current versions (including v17) it lives on the LogViewerService class in Umbraco.Cms.Core.Services:

public class LogViewerService : ILogViewerService
{
    private const int FileSizeCap = 100;

    // ...

    private bool CanViewLogs(LogTimePeriod logTimePeriod)
    {
        // ...sums file sizes for each day in the requested period...

        var logSizeAsMegabytes = fileSizeCount / 1024 / 1024;
        return logSizeAsMegabytes <= FileSizeCap;
    }
}

(In v13 and earlier, the same check lived on SerilogJsonLogViewer; the architecture was reworked but the cap itself is unchanged.)

It's not exposed as a config setting. To change it you'd register your own ILogViewerService - typically by extending LogViewerServiceBase and overriding CanViewLogsAsync. The Log Viewer documentation covers the extensibility model. That's a fair bit of effort to work around what is, ultimately, a logging volume problem.

Better to fix the noise at source.

Add a Serilog override to your appsettings.json:

"Serilog": {
  "MinimumLevel": {
    "Default": "Information",
    "Override": {
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "System": "Warning",
      "SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware": "Warning"
    }
  }
}

That last line tells Serilog to drop anything below Warning from the ImageSharp middleware specifically. You'll still see genuine warnings and errors - only the per-request INFO chatter goes away.

If you'd rather silence the entire SixLabors namespace (a couple of other loggers in there can also be chatty), use "SixLabors": "Warning" instead.

Heads up: you need an app pool recycle for this to take effect. Umbraco's default Serilog setup reads the configuration at startup and doesn't watch for changes to the logging pipeline. A recycle in IIS is enough - no full server restart needed.

If you're not already running a CDN in front of your Umbraco site, this is another good argument for one.

When an image is cached at the CDN edge, subsequent requests are served by the CDN and never reach your origin. No request to your server, no ImageSharp middleware invocation, no log entry. The first request from each edge location still hits origin and gets logged, but everything after that is silent.

CloudFront, Cloudflare, Bunny, or whatever you prefer - for a site serving a lot of media, the CDN dramatically reduces both your origin load and your log volume in one go. Pair it with the Serilog override above and you should see logs return to a sensible size.

Worth knowing while we're on the topic: Umbraco keeps 31 days of log files by default before the oldest start being deleted. Each day rolls into its own file (UmbracoTraceLog.MACHINENAME.20260427.json, etc.).

That retention is configured on the Serilog UmbracoFile sink, via RetainedFileCountLimit:

"Serilog": {
  "WriteTo": [
    {
      "Name": "UmbracoFile",
      "Args": {
        "RollingInterval": "Day",
        "RetainedFileCountLimit": 31,
        "FileSizeLimitBytes": 1073741824,
        "RollOnFileSizeLimit": false
      }
    }
  ]
}

Override it in your appsettings.json if 31 days isn't right for you - set 7 for a week, 90 for three months, or remove the property entirely to keep everything indefinitely (not recommended on a busy site).

Don't confuse this with Umbraco:CMS:Logging:MaxLogAge. That setting sounds related but it actually controls how long entries are kept in the umbracoLog database table - Umbraco's internal audit log. Nothing to do with the JSON files on disk.

One more thing worth flagging: that FileSizeLimitBytes of 1073741824 is a 1 GB cap on a single day's file. When a file hits that, Serilog stops writing to it (because RollOnFileSizeLimit is false by default - it won't roll over to a _001 companion file). This is separate from the 100 MB log viewer cap, so in theory you could end up with a log file that Serilog has stopped appending to but the backoffice still refuses to open. Yet another argument for fixing the noise at source rather than working around it.

The Serilog change won't help with logs that are already on disk. A few options:

• Compact Log Viewer - Warren Buckley's free desktop app. Reads the same CLEF/JSON format Umbraco writes, no size limit.

• Ship logs elsewhere - Application Insights, Seq, or Elastic via a Serilog sink. Worth doing on any production site of meaningful size.

• Just delete them. Once the noise is fixed at source, the next day's log file should be back to a reasonable size.

The 100 MB log viewer limit is one of those things that catches people out - you only find out about it when you really need to read the logs and can't. Getting the ImageSharp middleware quietened down is usually all it takes to stay well under the limit, and it's a one-line config change.

If a quick check of your logs shows hundreds of Sending image entries per minute, you know what to do.