12-Factor App Principle #11: Logs



This content originally appeared on DEV Community and was authored by Naval Kishor Upadhyay

Principle #11: Logs

Goal: Treat logs as event streams that are written to standard output, and let external tools handle storage, analysis, and archiving.

What It Means

  • Event streams: Logs should be a continuous, ordered flow of event data that describes what’s happening inside the app.
  • No log files: The app itself shouldn’t manage or store log files. Instead, write logs to stdout or stderr.
  • External aggregation: Use log management systems to collect, store, and analyze logs from multiple instances.
  • Real-time access: Logs should be viewable in real-time to help diagnose issues quickly.

Why It Matters

  • Centralized monitoring: Makes it easier to search, analyze, and correlate logs from different parts of the system.
  • Scalability: Works well in distributed systems where multiple instances are generating logs.
  • Troubleshooting: Real-time log streams help in quickly identifying and fixing problems.
  • Portability: No dependence on local storage or specific server setups.

Example

A Node.js app writes logs to stdout. In production, a service like ELK Stack (Elasticsearch, Logstash, Kibana) or Splunk collects and stores these logs. Developers and operations teams can search logs, create dashboards, and set alerts without changing the app’s code.

Best Practices

  1. Always write logs to standard output.
  2. Use structured logging (e.g., JSON) for easier parsing.
  3. Keep logs free of sensitive information.
  4. Integrate with centralized log management tools.
  5. Use log levels (info, warn, error) consistently.

Takeaway: Treat logs as real-time event streams, send them to external systems for processing, and keep your application stateless and portable.


This content originally appeared on DEV Community and was authored by Naval Kishor Upadhyay