Log Message Character Design Guide
In application development, log message design is a critical factor in operational quality. Well-sized log messages speed up root cause analysis during incidents and improve day-to-day monitoring efficiency. Overly verbose logs inflate storage costs and bury important information. This article covers recommended message lengths by log level, structured logging design, and the balance between cost and readability.
Recommended Length by Log Level
| Log Level | Message Length | Context Info | Use Case |
|---|---|---|---|
| FATAL / CRITICAL | 80–200 chars | Detailed (incl. stack trace) | System-stopping failures |
| ERROR | 60–150 chars | Detailed (error code, impact) | Processing failures, exceptions |
| WARN | 40–100 chars | Moderate (thresholds, values) | Potential issues, deprecations |
| INFO | 30–80 chars | Minimal (process name, result) | Normal operation records |
| DEBUG | 20–60 chars | Variable values, state changes | Development and debugging |
| TRACE | 10–40 chars | Function inputs/outputs | Detailed tracing |
Including metadata (timestamp, level, source file, line number), a single log line should generally stay within 200–500 characters.
The Scale of Logging at Big Tech
Netflix reportedly processes hundreds of terabytes of log data per day. Google's internal logging system is said to handle billions of log lines per second. At this scale, adding just 10 bytes per log line can increase annual storage costs by hundreds of thousands of dollars. This is why SRE teams at large-scale services are meticulous about log message length.
Structured Logging Format Design
Modern log management favors JSON-formatted structured logs over plain text. Structured logs are easier to search and filter, and integrate well with tools like CloudWatch Logs Insights and Elasticsearch.
| Field | Length Guide | Content |
|---|---|---|
| message | 30–150 chars | Human-readable message body |
| error_code | 5–20 chars | e.g., ERR_DB_CONN |
| request_id | 36 chars | UUID v4 format |
| user_id | 10–50 chars | User identifier |
| service_name | 5–30 chars | Microservice name |
| duration_ms | 1–10 chars | Processing time in milliseconds |
A typical structured log record should be 500 bytes to 2 KB. ERROR-level logs with stack traces may reach 5–10 KB, but normal logs should target under 1 KB.
Storage Cost Considerations
- AWS CloudWatch Logs: Ingestion $0.50/GB, storage $0.03/GB/month (us-east-1)
- 1 million lines/day: At 200 bytes average, that's ~200 MB/day, ~6 GB/month
- Reducing 50 bytes/line: Saves ~1.5 GB/month, ~$14/year in ingestion costs
Good vs. Bad Log Messages
- Bad: "Error occurred" (12 chars) — no indication of what failed
- Good: "Failed to connect to database: connection timeout after 30s" (59 chars) — cause and detail are clear
- Bad: "Processing..." (13 chars) — no indication of what's being processed
- Good: "Processing payment for order #12345, amount=$50.00" (50 chars) — target and content are explicit
SRE Best Practices
- Include grep-friendly unique tags: Tags like
[PAYMENT_FAILED]or[DB_TIMEOUT](10–20 chars) enable instant log extraction during incidents. - Use correlation IDs across services: A 36-character UUID in a
correlation_idfield lets you trace requests across API Gateway → Lambda → DynamoDB. - Dynamic log level switching: Run at INFO normally, switch to DEBUG via feature flags during incidents. Tools like AWS AppConfig enable this without redeployment.
- Standardize message templates: Use "verb + target + result + context" format. Example: "Failed to process payment: timeout after 30s, order_id=12345, retry_count=3"
Log Retention Guidelines
| Log Type | Retention | Reason |
|---|---|---|
| Access Logs | 90 days – 1 year | Security audits, intrusion investigation |
| Application Logs | 30–90 days | Incident investigation, performance analysis |
| Debug Logs | 7–14 days | Recent issue investigation only |
| Audit Logs | 1–7 years | Regulatory compliance |
Conclusion
Log message length should range from 20–200 characters depending on the log level. For structured logs, target under 1 KB per record and balance storage costs with readability. Messages that clearly convey "what happened" and "why" are the foundation of operational excellence. Use Character Counter to verify your log message lengths.