Monitoring turns failures into evidence that can be investigated. Logs record abnormal conditions, useful context, and causes so operators can trace infrastructure failures without exposing raw technical details to users or clients. In production, useful logs must reach persistent, aggregatable outputs rather than disappear in a console. section 7.1.2 section 7.3
Log selectively. A record earns its cost when it supports post-mortem investigation: technical failures normally do, while routine business-rule failures often do not. Rejected input such as a mistyped email address can create noise; repeated invalid login attempts may instead signal credential stuffing or password spraying and require logging, monitoring, and response. section 7.2.3
logger.error("Invalid number format for input: {}", input,
dataFormatException);
Use a logging API to state what failed, include relevant input context, and preserve the exception. The message should help reconstruct the failure while avoiding sensitive data. section 7.2.3 section 7.3
Treat a useful log entry as part of failure handling:
- Place it at the right failure boundary and severity level, where it adds diagnostic value rather than duplicating records upstream. section 7.3
- Describe the failed action and safe, relevant context; retain the original exception or cause for later diagnosis. section 7.3
- Avoid sensitive data and raw implementation details that could help an attacker or confuse a user. section 7.1.2 section 7.3
- Route production records to stores or centralized systems that support persistence, aggregation, collection, and monitoring. section 7.2.3 section 7.3
Following an HTTP 500 to its cause
When a form fails, reproduce the request and inspect the browser console and network trace. An HTTP 500 response moves the investigation to backend logs at the same timestamp; a stack trace can then identify the faulty line. When reproduction is impossible, build a timeline from logs, metrics, and other traces to reconstruct events. section 10.3.2 section 10.3.2
Use monitoring as a feedback loop, not a dumping ground. During hot exploration, watch a reproducible failure unfold from its first visible symptom toward the root cause. During cold exploration, use retained logs and related signals to infer the sequence left behind. The practical rule is simple: log what someone may need to act on later. section 7.2.3 section 10.3.2
