The overall log configuration also has a minimum level that's the first level of filtering - the default for that is Information, hence the MinimumLevel.Debug() making the difference.

After that, each sink to which events are being written can impose a more restrictive filter at the point of entry - i.e. the default you are referring to is being applied, but you're correct that the restrictedToMinimumLevel: LogEventLevel.Debug) has no real effect (though IIRC that would still cause the sink not to emit a Verbose message, assuming the top level pipeline was configured with that as its minimum level).

NOTE: in future, you're best off asking usage questions like this on stackoverflow.com as the template suggests; you'll normally get much quicker answers, and the issue tracker has one less issue...

Gotcha, thanks.

However, I do question why the README in this repo shows DBG logs in the screenshot of the console window when the code in the blocks above it will not be able to produce any DBG level logs (this is the code I was going by while integrating this library to my codebase).

It's mighty confusing that a debug log sink's setup instructions do not allow the production of debug level logs out of the box without extra logger config that isn't directly documented (unless it is documented and I'm blind).

Oh, that's a good catch in that instance - a PR to fix the readme would be much appreciated.

I can remember being confused by the default minimum level and why stuff wasnt appearing myself, though the default does make sense to me in terms of trying to keep logs sane.