The default handler

April 7, 2026

Much like the older log package, log/slog ships with a “default logger”. You can use this logger without doing any configuration, just by calling any of the package-level logging functions:

slog.Error("oh noes!")

While you’d probably never want to use the default logger in a serious server application, it can be a convenience for small or throw-away utilities. But how does it work? That’s today’s topic!

Overview

The default handler formats the log record’s message, time, level, and attributes as a string and passes it to the log package.

2022/11/08 15:28:26 INFO hello count=3

So that’s doubly convenient—not only does it log things in a reasonable format, but it also passes them to the log package for backward compatibility. This means that if your application already takes advantage of the default log package’s logger, you don’t need to do any additional configuration to start using log/slog. Sweet!

But wait… how does the default log package’s logger work? Well, it’s pretty limited (which is, of course, largely why log/slog was added to replace it!) By default, it simply writes to STDERR. Though you can configure the default log.Logger… a little bit—mainly by redirecting where those logs go (e.g. to a file). But that’s a good segue into the default logger configuration we do care about—you can also configure the log/slog default logger, which we’ll talk about tomorrow!


Share this

Direct to your inbox, daily. I respect your privacy .

Unsure? Browse the archive .

Related Content


Concurrent logging

One last note in the performance section… How does logging work in a concurrent system? Performance considerations … The built-in handlers acquire a lock before calling io.Writer.Write to ensure that exactly one Record is written at a time in its entirety. Although each log record has a timestamp, the built-in handlers do not use that time to sort the written records. User-defined handlers are responsible for their own locking and sorting.


Back after an unannounced absence

Hey everyone… I dropped the ball! A combination of unexpected family events, prepping for a conference, and some travel, meant I haven’t been writing for much longer than I like. But I’m back! So where were we? Oh that’s right… performance considerations with log/slog. We had looked at using the fmt.Stringer interface to avoid eager processing with slog.TextHandler. But let’s now look at a more general solution: Performance considerations …


Lazy attribute evaluation for JSONHandler

As I was writing yesterday’s post, a portion of the GoDoc confused me. I’ve now spent over 3 hours with Claude trying to parse the prose grammatically, build test cases, and make general sense of it. I think I finally have… Here’s hoping! So, yesterday we saw how you can lazy-evaluate some values when using TextHandler. But the proposed solution (pass a fmt.Stringer rather than a literal string) has other, likely uninintended, consequences if you’re using JSONHandler:

Get daily content like this in your inbox!

Subscribe