What to Log in a Java Backend Application
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
My rule for what to log is simple: log what you'd want to have at 3 AM during an incident.
Concretely, that's a few categories. First, significant business events — an order was placed, a payment was processed, a user registered. These give you the narrative of what the system is doing.
Second, the inputs and outputs at boundaries — when a request comes in and when you call a downstream service — so you can see what data crossed the line. Third, errors, always with the full stack trace and business context. And fourth, important state transitions, like an order moving from pending to shipped.
The critical thing is that every one of these should carry identifiers — an order ID, a user ID, a request ID — so that when you're investigating you can correlate all the lines for one transaction. A log line with no identifiers is almost useless. Now the don'ts.
Never log secrets or personal data — passwords, authentication tokens, card numbers, or full request bodies that might contain them. That's both a security risk and a compliance violation, so you redact those fields before logging. And don't log every internal detail at INFO; routine stuff like loop iterations or cache hits belongs at DEBUG so it stays out of production logs.
The balance I'm aiming for is enough that I can reconstruct any incident, but not so much that the signal gets buried in noise. If I ask myself, would I actually need this line to diagnose a production problem, and the answer is no, it's probably noise or it belongs at DEBUG.
What to Log in a Java Backend Application
Direct Answer
Log events needed to operate and investigate the service: lifecycle changes, important business outcomes, dependency failures, rejected requests, and safe correlation identifiers. Record unexpected exceptions once at a meaningful handling boundary. Do not log passwords, session secrets, access tokens, full payment data, or unneeded personal information.
Deep Dive & Architecture
A good log answers what operation occurred, whether it succeeded, and which safe identifier connects it to related work. Examples include order_created, a retry after a dependency timeout, or a message moved to a dead-letter queue.
At service boundaries, record safe metadata rather than entire request and response bodies. An order ID, status, duration, and correlation ID are usually more useful and less risky than a serialized customer object. Validate local privacy and audit requirements before treating any user identifier as safe.
Log an unexpected exception with its stack trace at the layer that handles or reports it. Logging the same exception at every layer creates duplicates. Expected validation failures may need a concise event or metric rather than an ERROR stack trace.
Code Example
public OrderResult checkout(CheckoutRequest req) {
// Boundary in: WHO and WHAT, never card data
log.info("Checkout start: userId={}, items={}", req.userId(), req.itemCount());
try {
OrderResult r = process(req);
log.info("Checkout ok: orderId={}, total={}", r.orderId(), r.total()); // business event
return r;
} catch (PaymentDeclinedException e) {
log.info("Checkout declined: userId={}, reason={}", req.userId(), e.code()); // expected
throw e;
} catch (Exception e) {
log.error("Checkout failed: userId={}", req.userId(), e); // failure + stack trace
throw e;
}
}
// NEVER: log.info("card={}", req.cardNumber()); <-- secret leak
Common Mistakes & Pitfalls
- No identifiers: 'order failed' with no order or user ID — impossible to investigate.
- Logging secrets: card numbers, passwords, tokens, or whole request bodies — a security and compliance breach.
- Everything at INFO: dumping internal loop detail at INFO, drowning the real business events.
Check your understanding
Answer these without looking back at the article.
- What are debugging and logging and why do they matter from day one? Debugging is finding and fixing defects; logging is recording what your program did — together they are how you understand code that isn't doing what you expect.
- Why is logging important in a Java backend application?
- What is structured logging and why is it preferred over plain text logs?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.