What Is Logging Best Practice in Production
SkillVeris Team
Cloud & Security Team
Good production logging means writing structured, leveled, searchable logs that let you reconstruct what happened without logging sensitive data.
In this guide, you'll learn:
- Structured logs in JSON with consistent fields are queryable at scale, unlike free-text lines you can only grep.
- Log levels — DEBUG, INFO, WARN, ERROR — let you control verbosity and filter to what matters during an incident.
- Correlation IDs tie every log line from one request together, even as it crosses multiple services.
- Never log passwords, tokens, card numbers, or personal data — it is a security and compliance risk that lingers in storage.
1What Is Good Production Logging?
Good production logging means recording events in a structured, leveled, searchable way so you can reconstruct exactly what your system did — without ever logging sensitive data. Logs are the narrative of your application, and in production that narrative has to be both useful and safe.
The difference between helpful and useless logs is rarely the volume. It is structure, context, and discipline: consistent fields you can query, the right level of detail, a way to follow a single request, and a firm rule against leaking secrets into log storage.
2Structured Logging
The single biggest upgrade to production logs is making them structured. Instead of a free-text sentence, each log is a JSON object with named fields, so a log platform can index and query it precisely.
- Bad: 'User 42 failed login from 10.0.0.5'
- Good: { "event": "login_failed", "user_id": 42, "ip": "10.0.0.5", "level": "warn" }
- Structured logs let you filter by field: all login_failed events for user_id 42.
- They aggregate cleanly — count events, group by field, build charts.
🔑Why It Matters
At production scale you do not read logs, you query them. Structure turns millions of lines into a searchable dataset instead of a haystack.
3Using Log Levels Well
Log levels let you attach a severity to each message so you can filter noise from signal. Using them consistently is what makes verbosity controllable in production.
- DEBUG: detailed diagnostic info, usually off in production.
- INFO: normal significant events — a request served, a job completed.
- WARN: something unexpected but handled — a retry, a deprecated call.
- ERROR: a failure that needs attention — an unhandled exception, a failed transaction.
- FATAL/CRITICAL: the application cannot continue.
Set the Right Default
Run production at INFO and above, with the ability to raise verbosity to DEBUG temporarily when investigating. Logging every DEBUG line permanently is expensive and buries the events that matter.
4Correlation IDs and Context
In a system of multiple services, a single user action produces log lines scattered across many processes. A correlation ID — a unique identifier generated at the entry point and passed along — ties them all back together.
Attach it as a field on every log line so that searching by one request ID returns the complete story of that request across services. Add other stable context too, such as user ID, tenant, and environment, so you can slice logs the way an incident demands rather than guessing.
💡Thread It Through
Generate a request ID at the edge (or accept an incoming trace header), store it in request context, and include it in every log automatically. Manual passing is where the chain breaks.
5Never Log Secrets or PII
The most important safety rule of production logging is that secrets and personal data must never reach the logs. Logs are copied, shipped to third-party platforms, and retained for a long time, so anything logged is effectively broadcast and stored.
This is both a security risk and a compliance one under regulations like GDPR. A leaked token in a log is a live credential; a logged card number or health record is a reportable data exposure. Treat log output as a place attackers and auditors will eventually look.
- Never log passwords, API keys, tokens, or session cookies.
- Redact or mask card numbers, government IDs, and health data.
- Be careful logging full request or response bodies — they often contain secrets.
- Scrub sensitive fields automatically in your logging middleware, not by hoping developers remember.
6Common Mistakes to Avoid
Most production logging pain comes from a handful of recurring habits.
- Logging unstructured free text that cannot be queried or aggregated.
- Logging everything at one level, so real errors hide among routine noise.
- Printing secrets, tokens, or personal data straight into logs.
- Writing logs only to local files, so they vanish when a container is replaced.
⚠️Watch Out
Logs written to a container's local disk disappear when the container restarts. Ship logs to a central system, or your most important evidence is gone exactly when you need it.
7Best Practices
A few durable practices keep production logs an asset rather than a liability.
- Log structured JSON with consistent field names across all services.
- Centralise logs in a platform (ELK, Loki, or a hosted service) rather than scattered files.
- Include a correlation ID and useful context on every line.
- Redact secrets and PII automatically in shared logging middleware.
- Sample or rate-limit high-volume, low-value logs to control cost and noise.
- Set retention policies that balance debugging needs against storage and compliance.
8Key Takeaways
The essentials of production logging come down to a few durable principles.
- Structured JSON logs are queryable at scale; free text is not.
- Use log levels consistently and run production at INFO with on-demand DEBUG.
- Correlation IDs stitch a single request together across services.
- Never log passwords, tokens, or personal data — redact automatically.
- Centralise logs and sample noisy ones so signal survives the volume.
9Frequently Asked Questions
Q: Why should logs be structured as JSON? A: Because at production scale you query logs rather than read them. JSON gives each log named fields a platform can index, so you can filter by user, event, or request ID and aggregate across millions of lines — impossible with free-text messages.
Q: What log level should I use in production? A: Run at INFO and above by default, capturing significant events, warnings, and errors while keeping volume manageable. Keep the ability to raise the level to DEBUG temporarily when investigating a specific issue, then lower it again.
Q: What is a correlation ID? A: A unique identifier generated when a request enters your system and attached to every log line it produces, even across multiple services. Searching by that one ID returns the complete story of a single request, which makes debugging distributed systems tractable.
Q: Is it ever okay to log passwords or tokens? A: No. Logs are copied, centralised, and retained, so anything logged is effectively stored and exposed. Logging credentials or personal data is both a security risk and a compliance violation. Redact or mask sensitive fields automatically before anything is written.
Related Reading
Get The Print Version
Download a PDF of this article for offline reading.
About the Publisher
SkillVeris Team
Cloud & Security Team
Our cloud and security experts break down complex infrastructure topics into practical, beginner-friendly guides.
View all postsRelated Posts
Never miss an update
Get the latest tutorials and guides delivered to your inbox.
No spam. Unsubscribe anytime.