// the take
zerolog is a structured JSON logging library for Go built around a zero-allocation, chaining API. It's aimed at Go services where logging overhead matters — high-throughput APIs, infra tooling, anything already emitting JSON logs to stdout for a log aggregator to pick up.
The allocation story is real and verified in the benchmarks, not just marketing: sub-allocation logging even with 10 contextual fields, which matters at high QPS where logrus/apex-style reflection-based loggers show up in profiles. The API forces you to end a chain with Msg/Msgf, which is a deliberate tradeoff for performance (no interface boxing until the last step). Native log/slog.Handler integration means you can standardize on the stdlib API while still getting zerolog's encoder underneath. hlog middleware for net/http and Hook support cover the two things people actually need to bolt logging into a service.
If you forget the trailing Msg()/Msgf() call the log silently never fires — no compile error, no runtime warning, just a dropped log line, and that's a real footgun in a codebase with many contributors. The Event object is sync.Pool-backed and explicitly not safe to retain past Msg() — any code that stashes a *zerolog.Event in a closure or hook and uses it later gets silent corruption, which is a sharp edge for less careful contributors. Console pretty-printing is explicitly called out as inefficient, so it's not something to leave on in any latency-sensitive path, only for local dev. Field de-duplication isn't handled at all — duplicate keys land twice in the JSON, and which one wins is consumer-dependent, which can bite you quietly in log pipelines that assume last-value-wins or first-value-wins consistently.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →