What Every Log Message Should Include

Direct Answer

There is no useful field that every application log call must repeat. The logging system normally adds timestamp, level, and logger; the code should add a stable event or clear message plus only the safe context needed to understand it. Add correlation and business identifiers when relevant, and include an exception stack trace for an unexpected failure at its handling boundary—not for every error-level event.

Deep Dive & Architecture

The logging provider normally supplies transport metadata such as timestamp, level, logger, and sometimes thread. Application code should supply a clear event name or message and the few fields that explain that event.

For an order failure, useful fields might be orderId, requestId, dependency=payments, and outcome=timeout. A scheduled startup event may need none of those. Repeating every possible field on every line increases noise and may expose personal data.

Attach the exception object when an unexpected failure is first handled or reported so its type, message, causes, and frames are preserved. Do not log the same stack trace at every layer, and do not use an ERROR stack trace for ordinary validation results.

Code Example

// Good: message + identifiers; framework adds time/level/class/thread
log.info("Order placed: orderId={}, customerId={}, total={}",
         order.id(), order.customerId(), order.total());
// Output: 2026-06-04 10:23:45.123 INFO [http-nio-8080-exec-3] OrderService
//         - Order placed: orderId=42, customerId=7, total=99.99

// Errors: pass the exception OBJECT (last arg) to capture the stack trace
try { charge(order); }
catch (PaymentException e) {
    log.error("Payment failed: orderId={}", order.id(), e); // full trace included
    // BAD: log.error("Payment failed: " + e.getMessage()); // trace lost
}

Common Mistakes & Pitfalls

• No identifiers: 'save failed' with no order/user ID — can't tie it to anything.
• Losing the stack trace: logging e.getMessage() as a string instead of passing the exception object.
• Vague messages: 'something went wrong' tells the on-call engineer nothing actionable.