This one’s for every dev who has yelled, “Why isn’t my logger working?!” only to discover that… it was. It just wasn’t working for your part of the app.

That was me a few days ago — sprinkling LogInformation calls like seasoning into a new service class, confident I’d see those sweet, sweet logs. But when I ran the app? Silence. No output. Not even a whisper.

ILogger wasn’t broken. It just didn’t care what I had to say.

The Problem

I was working in a .NET Web API project, and logging in my controllers was working perfectly. So naturally, I assumed my service class logs would show up too. I added a few logger.LogDebug() and logger.LogInformation() lines inside a service called CoffeeBrewer, hit the endpoint, and… nothing appeared in the console.

No exceptions. No errors. Breakpoints confirmed the code was running — but it was like ILogger had ghosted me.

The Solution

After a bit of digging, I opened my appsettings.json and found this innocent-looking config:

"LogLevel": {
  "MyApp.Controllers": "Information",
  "Default": "Warning"
}

That’s when it hit me. My controller logs showed up because they fell under the "MyApp.Controllers" category — explicitly set to "Information". But my service? It was under the "MyApp.Services" namespace and not explicitly configured, so it fell back to "Default": "Warning".

That meant all my Debug and Information logs were being silently ignored. ILogger was doing its job — just not for my category.

To fix it, I updated the config:

"LogLevel": {
  "MyApp.Controllers": "Information",
  "MyApp.Services": "Information",
  "Default": "Warning"
}

Boom. My logs came back to life like a caffeine-powered resurrection.

Deeper Explanation

When you use ILogger<T>, the category attached to each logger is the fully qualified class name. You can define log levels per category in your appsettings.json. If a class’s category isn’t explicitly listed, it falls back to the "Default" level.

And this comes straight from the official documentation (Microsoft Learn):

Creates an ILogger with a category named 'Program'. The category is a string that is associated with each message logged by the ILogger object.

So in my case, everything logged from MyApp.Services.CoffeeBrewer was filtered out by the default Warning setting—unless I explicitly allowed its category.

Best Practices

• Be explicit: Define log levels for all namespaces or class categories where you’re actively working.
• Know your categories: ILogger<T> uses the class’s fully qualified name as its logging category.
• Don’t trust only "Default": Especially during development, that setting may suppress logs from large sections of your application.
• Use Debug or Trace levels responsibly: Great for development insights, but remember to scale back in production.

Conclusion

So, if your logs mysteriously vanish in one part of your app but appear elsewhere, double-check your category-based logging configuration.

ILogger didn’t ghost me — I just forgot to invite it to my class.