Logs are often treated as files to read after something breaks. In reality, log design decides whether a team can answer four questions: who accessed what, where errors occurred, whether forms were delivered, and who changed configuration. Unstructured logs consume space without improving judgment.
Access logs answer entry questions
Record time, path, status code, source IP, user agent, response time, and necessary referrer information. These logs expose scanning, regional failures, old-link 404s, and sudden asset traffic.
Error logs answer system questions
Error logs should include type, request context, service name, and time without leaking passwords, private keys, or complete personal data. Node services, proxies, databases, and third-party integrations need documented log locations.
Form logs answer business questions
Record whether a submission entered storage, whether captcha failures are abnormal, and whether notifications were sent. When a customer says a form was submitted but no response arrived, the team needs evidence.
| Log | Use | Retention |
|---|---|---|
| Access | Traffic, status, source | Rotate by capacity |
| Error | Incidents and dependencies | Align with release cycle |
| Form | Lead verification, spam | Follow privacy policy |
| Change | Release, config, permission | Keep long-term summaries |
Retention must consider privacy and cost
Logs may contain IP addresses, paths, form fields, and internal operations. Keep detailed logs for short periods and preserve long-term summaries for key changes. This supports troubleshooting while reducing unnecessary data risk.