Building Slogbox

Dev builds a “DVR for your logs” — the crowd can’t decide if it’s genius or risky

TLDR: Slogbox is a lightweight tool that keeps only your most recent logs in memory, like a DVR, so you can pull a snapshot when trouble hits. The crowd is split between fans praising its speed and simplicity and skeptics worried about privacy, memory limits, and reinventing logging basics.

A Go dev just dropped “slogbox,” a tiny add-on that keeps only the latest slice of your app’s logs—think a DVR for error messages. It’s inspired by Go’s new FlightRecorder feature (a circular memory for recent data) and aims to be blazing fast by storing raw records and formatting only when you actually look at them. Simple idea, big reactions.

Early commenters latched onto the pitch—keep the last N log lines in memory and snapshot them on demand—and the thread turned into a tug-of-war. The “on-call heroes” are cheering: finally, a lightweight way to grab what just happened when things go sideways, without drowning in log firehoses. Meanwhile, skeptics are rolling eyes: do we really need Yet Another Logging Thing, or should teams fix their pipelines instead? Privacy hawks popped in with caution tape: if logs can contain sensitive stuff, even a tiny memory buffer can be a tiny liability. Ops folks worried about memory caps and noisy apps, while performance nerds loved the no-append, modulo-math ring buffer and the “only serialize on read” design.

The memes arrived fast: “It’s a dashcam for your backend,” joked one dev; another teased, “Congrats, you reinvented a black box—but for logs.” Love it or hate it, slogbox sparked a surprisingly spicy debate about speed vs. safety vs. simplicity.

Key Points

  • slogbox is a Go slog.Handler that stores the last N structured log records in a fixed-size in-memory ring buffer.
  • The implementation uses a pre-allocated slice with modulo arithmetic to avoid allocations and GC overhead on the hot path.
  • Snapshot reads handle wraparound by copying from the head to end and then start to head, allocating only the output slice.
  • Benchmarks indicate ~150 ns/op per Handle call with a single allocation from attribute merging, not from the ring buffer.
  • The buffer stores raw slog.Record values, deferring serialization to read time, with APIs for full, filtered, and iterable access.

Hottest takes

"a slog.Handler backed by a fixed-size ring buffer" — zimpenfish
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.