The day a logging config ate half my heap

Memory crept up under load. Not a spike — a climb. The kind that ends in an OOM kill a few hours later. I went hunting for a leak and found something more embarrassing: there was no leak. The system was doing exactly what I had told it to. I had just told it to remember too much.

The good intention

On the flows that matter most — order creation, payments, refunds — we log the full request and response body. When money moves and a customer disputes a charge, "what exactly did the client send, and what did we return?" is the difference between a five-minute answer and a forensic afternoon. A single interceptor captures it:

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(ctx: ExecutionContext, next: CallHandler) {
    const req = ctx.switchToHttp().getRequest();
    return next.handle().pipe(
      tap((responseBody) => {
        logger.info({
          route: `${req.method} ${req.url}`,
          status: ctx.switchToHttp().getResponse().statusCode,
          // full payloads on critical routes ONLY — never globally
          ...(isCritical(req.url) && { requestBody: req.body, responseBody }),
        });
      }),
    );
  }
}

Note the discipline already baked in: full bodies on critical routes only. Everywhere else we log metadata — method, path, status, a correlation id — and nothing more. That restraint is the only reason this story is about memory and not about leaking customer data into log files.

Where the memory actually went

Here is the part I hadn't internalised: a logged object isn't free, and it isn't fire-and-forget. A structured logger serialises the whole object graph, and the transport buffers it before it ships. Until that buffer drains, every captured body — a cart with forty line items, a fat provider response — stays alive on the heap. Now multiply by request rate.

Under normal traffic the buffer drains faster than it fills and you never notice. Under load it inverts: bodies arrive faster than the transport flushes, the queue grows, and the queue is made of large objects that can't be collected. On a graph it looks exactly like a leak. It isn't. It's backpressure in your logger.

The fix wasn't logging less

The reflex is "turn off the body logging." Wrong — that capability is genuinely valuable on the critical paths. The fix is logging deliberately:

• Scope it — full bodies only where they earn it (money, auth, disputes). Never globally.
• Cap the size — truncate any body over a few KB. A 2 MB upload has no business in a log line; a one-line note that it was elided does.
• Redact first — strip card data, tokens, and PII before anything reaches the logger, as a separate pass.
• Bound the buffer — give the transport a ceiling and let it sample or drop under pressure, so the logger can never be the thing that OOMs you.
• Prefer ids everywhere else — log the orderId, not the order. You can always fetch the rest; you can't un-hold a million objects.

Observability has a price, and the bill comes due under exactly the load where you most want the logs. The cheapest log line is the one you decided, on purpose, not to keep. I didn't log less after this — I logged on purpose.