drippa
Back to drippa

One Error, One Log Entry

tl;dr: Production errors now land as a single, properly-tagged log entry instead of fifteen anonymous fragments.

Published Sunday, August 16, 2026

A single failure used to arrive as roughly fifteen log entries. Message on one line, every stack frame on its own, all of them filed under the blandest severity available — which meant searching for errors in production returned exactly nothing. The stack traces were there. They were just scattered across the timeline like confetti.

Server-side logging now emits single-line structured JSON, with the message and its full stack in one field and a real severity attached. One failure, one entry, correctly tagged. The change hooks in at boot rather than asking every call site to import a new logger, so all ~190 existing log calls were fixed without touching them — and it also captures output from code we don't own, like framework-level errors and third-party warnings that a call-site migration would have missed entirely.

Message text is byte-for-byte what it was before; only the packaging changed. Local development keeps its human-readable output, because staring at raw JSON while you debug is its own kind of punishment. The behavior mirrors what our backend services already do, so logs from both halves of the stack finally speak the same language.

What this unlocks is unglamorous and important: when something breaks in production, on-call can find it in seconds instead of reassembling a stack trace by hand. Faster diagnosis, faster fixes, fewer incidents that drag on because the evidence was hard to read.

Nobody will ever see this feature. Everyone benefits from it — quieter incidents, faster fixes.