Logging
LOG-ing
Recording timestamped events from an application to help with debugging and auditing.
Logging is writing down what your application is doing. Every significant event, decision, and error gets recorded with a timestamp. When something goes wrong at 3am, logs are how you figure out what happened.
Structured logging is the modern standard. Instead of writing "User 123 logged in" as a plain string, you write a JSON object: {"event": "user_login", "user_id": 123, "timestamp": "2024-01-15T03:14:00Z", "ip": "192.168.1.1"}. Structured logs can be searched, filtered, aggregated, and analyzed programmatically. Plain text logs require regex and prayer.
Log levels matter. DEBUG is for development. INFO is for normal operations. WARN is for concerning but non-critical issues. ERROR is for failures that need attention. FATAL is for crashes. The difference between a useful logging system and a noisy one is choosing the right level for each message. Log everything at DEBUG in development. Log INFO and above in production. Reduce noise so the important signals stand out.
Examples
A developer debugs a payment failure.
The logs show: INFO 'Payment initiated for order_id=5678, amount=$99.00.' WARN 'Card processor returned soft decline, retrying.' ERROR 'Payment failed after 3 retries, error=insufficient_funds, user_id=123.' The developer can see the full sequence of events, the retry behavior, and the final failure reason without asking the user what happened.
A team migrates from unstructured to structured logging.
The old logs look like: 'Error processing request from user 123: database timeout.' The new logs look like: {"level": "error", "event": "request_failed", "user_id": 123, "error": "database_timeout", "duration_ms": 30000, "service": "order-api"}. The team can now query 'show all database timeouts in the last hour' instead of grepping through gigabytes of text.
An audit requirement drives logging improvements.
A fintech company needs to log every data access for SOC 2 compliance. They implement an audit logging layer that records who accessed what data, when, and from which IP address. The audit logs are stored separately with immutable retention for 7 years. When an auditor asks 'who accessed customer 456's records in Q3?', the answer is a single query.
In practice
Read more on the blog
Frequently asked questions
What should you log and what should you not log?
Log: authentication events, errors with context, business-significant actions (payments, signups), and performance data. Do not log: passwords, API keys, credit card numbers, personal health information, or any data protected by regulation. A good rule: if the log entry would be a security incident if it leaked, do not log it. Mask or hash sensitive identifiers when you need them for debugging.
How long should you keep logs?
It depends on your needs and compliance requirements. Most teams keep application logs for 30-90 days. Security and audit logs often require 1-7 years. The trade-off is storage cost versus diagnostic value. Logs from six months ago rarely help debug today's issues. But regulatory requirements may mandate longer retention. Use tiered storage: hot storage for recent logs, cold storage for compliance.
Related terms
The ability to understand a system's internal state by examining its outputs: logs, metrics, and traces.
Following a request's path through distributed services to understand performance and find failures.
Continuously checking system health using metrics, dashboards, and alerts to detect problems.
Automatically notifying engineers when system metrics cross predefined thresholds indicating problems.
An unplanned event that disrupts a service or degrades it below its expected quality, requiring a coordinated response.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.