Logging is one of those things every developer does and almost no one does consistently. Open any mature codebase and you'll find a museum of logging styles: console.log from early development, logger.info from when someone added a logging library, debug() from a different developer's preference, and printf statements from legacy code nobody wants to touch.
Inconsistent logging isn't just aesthetically unpleasant - it's operationally painful. When production catches fire at 3 AM, you need to search logs quickly. Inconsistent formats break log aggregation. Missing context makes debugging impossible. Varying log levels mean your alerts trigger on noise while missing actual problems.
AI agents can analyze your entire codebase, understand your logging patterns, and standardize them automatically. Every console.log becomes a proper structured log. Every missing context field gets added. Every incorrect log level gets fixed.
Why Logging Standards Drift
Teams don't start with inconsistent logging - they evolve into it.
Multiple Contributors
Developer A uses console.log for quick debugging. Developer B prefers logger.info. Developer C uses a custom logging wrapper from a previous project. None of them are wrong individually, but together they create chaos.
Historical Layers
Code written in 2019 uses the logging approach that was standard then. Code from 2022 uses what was recommended at that time. Code from last week uses the current best practice. The codebase becomes a timeline of logging philosophies.
Inconsistent Enforcement
Teams adopt logging standards, write them down, and forget to enforce them. New code sometimes follows the standard, sometimes doesn't. Nobody wants to be the person who comments "please use the logger" on every PR.
Emergency Code
When production is down, developers add logging that helps diagnose the immediate problem. They don't carefully follow standards. The emergency passes, but the inconsistent logging remains.
Copy-Paste Inheritance
Developers copy code patterns, including logging patterns. If the source has non-standard logging, every copy propagates the problem.
What Needs Standardization
Logging has many dimensions that benefit from consistency.
Log Output Method
Every log should use the same mechanism:
@devonair replace all console.log statements with our structured logger
@devonair standardize all logging to use the winston logger instance
Log Levels
Appropriate levels for appropriate situations:
@devonair audit all log statements and correct inappropriate log levels
@devonair ensure error logs are only used for actual errors, not warnings
Message Format
Consistent message structure:
@devonair standardize log messages to format: [Context] Action - Details
@devonair ensure all log messages start with a capitalized verb
Structured Data
Machine-readable context:
@devonair add structured metadata to all log statements: userId, requestId, timestamp
@devonair convert string interpolation in logs to structured objects
Error Logging
Proper error capture:
@devonair ensure all error logs include stack traces and error context
@devonair standardize exception logging to include error type and message
Standardization Patterns
The Full Sweep
Convert everything at once:
@devonair standardize all logging in /src to use our logging utility with proper levels and context
Best for: Smaller codebases, comprehensive test coverage.
The Incremental Approach
Standardize by module:
@devonair standardize logging in /src/api to use structured logging
Then:
@devonair standardize logging in /src/services with the same pattern
Best for: Large codebases, gradual adoption.
The Priority Approach
Start with production-critical code:
@devonair standardize logging in /src/payments and /src/auth first
@devonair ensure all error handling paths have proper logging
Best for: When some code matters more than others.
The New Code First
Prevent new inconsistency:
@devonair on PR: verify new code follows logging standards
@devonair on PR: suggest logging standardization for non-compliant patterns
Then backfill:
@devonair schedule weekly: standardize logging in 10 files
Structured Logging
Modern logging should be structured for machine consumption.
From String Concatenation
Before:
console.log('User ' + userId + ' performed action ' + action + ' on ' + resource);
After:
logger.info('User action performed', { userId, action, resource });
@devonair convert string concatenation in logs to structured objects
From Template Strings
Before:
console.log(`Request ${requestId} failed with status ${status}`);
After:
logger.error('Request failed', { requestId, status });
@devonair convert template string logs to structured log objects
Adding Context
Before:
logger.info('Order created');
After:
logger.info('Order created', { orderId, userId, totalAmount, itemCount });
@devonair enrich log statements with relevant context from surrounding code
Log Level Correction
Proper log levels enable effective alerting and filtering.
Level Guidelines
- error: Something failed that shouldn't have. Requires attention.
- warn: Something concerning but handled. Monitor for patterns.
- info: Normal operations worth recording. Business events.
- debug: Development details. Disabled in production.
@devonair review all log levels and ensure they follow our guidelines
Common Corrections
@devonair change console.log to appropriate log level based on context
@devonair downgrade info logs that should be debug in /src/internal
@devonair upgrade warn logs that indicate actual errors
Conditional Debug Logging
@devonair wrap verbose debug logging in log level checks
Prevent debug log creation overhead in production.
Error Logging Standardization
Errors need special attention.
Stack Trace Inclusion
@devonair ensure all error logs include the full stack trace
You'll need that stack trace at 3 AM.
Error Context
@devonair add request context to all error logs in /src/api
@devonair include input parameters in error logs where safe
Error Categories
@devonair add error type categorization to all error logs
Enable filtering by error type.
Error Chaining
@devonair preserve original error when wrapping exceptions in new errors
Don't lose the root cause.
Request Context
Every log in a request should be traceable.
Request ID Propagation
@devonair add requestId to all logs within request handlers
Trace logs across a single request.
User Context
@devonair add userId to all logs where user context is available
Track user-specific issues.
Correlation IDs
@devonair implement correlation ID propagation across async boundaries
Trace logs across services.
Sensitive Data Protection
Logs should never contain sensitive data.
PII Detection
@devonair identify and redact potential PII in log statements
Email addresses, phone numbers, addresses - redact them all.
Credential Protection
@devonair ensure passwords, tokens, and API keys are never logged
@devonair replace raw request bodies with sanitized versions in logs
Compliance
@devonair audit logs for GDPR/CCPA compliance issues
Regulatory requirements apply to logs too.
Performance Considerations
Logging shouldn't hurt performance.
Lazy Evaluation
@devonair wrap expensive log computations in level checks
Don't compute debug log content in production.
Async Logging
@devonair ensure logging doesn't block request handling
Logs should write asynchronously.
Log Volume
@devonair identify high-volume logs that should be sampled
Not every debug log needs to be written.
Testing Logging
Logs are features that need testing.
Log Output Verification
@devonair add tests that verify critical operations produce expected logs
Log Level Testing
@devonair verify error conditions produce error-level logs
Context Verification
@devonair test that logs include required context fields
Logging Library Setup
Before standardization, you need a proper logging infrastructure.
Logger Configuration
@devonair configure winston/pino with structured JSON output
@devonair set up log level configuration from environment variables
Log Formatting
@devonair configure log format for development (pretty) and production (JSON)
Log Destinations
@devonair configure log output for console, file, and log aggregator
Migration Strategies
From console.log
@devonair replace all console.log with logger.debug or logger.info as appropriate
@devonair replace all console.error with logger.error with proper context
From Mixed Libraries
@devonair standardize to a single logging library, replacing all others
From Printf-Style
@devonair convert printf-style logs to structured logging format
Maintaining Standards
Standards without enforcement decay.
PR-Level Checks
@devonair on PR: block non-standard logging patterns
@devonair on PR: suggest corrections for logging issues
Scheduled Audits
@devonair schedule monthly: report on logging standard compliance
Documentation
@devonair document logging standards in /docs/logging.md
Clear documentation enables compliance.
Measuring Logging Health
Track logging quality over time.
Standard Compliance
@devonair report on percentage of logs that follow standards
Log Volume Analysis
@devonair analyze log volume by level and identify outliers
Error Rate Tracking
@devonair correlate error log volume with actual error rates
Getting Started
Start with the simplest standardization:
@devonair replace all console.log statements with logger.info
Then add structure:
@devonair convert string logs to structured log objects
Then add context:
@devonair add requestId and userId to all logs where available
Set up enforcement:
@devonair on PR: flag non-standard logging for review
Logs that follow standards are logs you can actually use. When your logging is consistent, your 3 AM debugging sessions get shorter.
FAQ
Should I log everything?
No. Log business events (orders, signups, failures), errors, and enough context to debug problems. Avoid logging routine success cases that add volume without value.
What about log rotation and retention?
That's infrastructure, not code. But your code should assume logs are ephemeral and include enough context to be useful on their own.
How do I handle logging in libraries?
Libraries should accept a logger interface, not create their own. This lets applications control logging configuration for all dependencies.
What about performance-sensitive code paths?
Use debug-level logs with level checks. In production, the log statement never executes. In development, you have the visibility you need.