Write logs that explain an operation
Log the operation and its result with structured fields. Include an identifier that helps connect the message to a resource or job, without logging credentials or complete private request data.
?LOG_ERROR(#{
text => <<"Garden update failed">>,
in => mod_garden,
result => error,
reason => Reason
}).
Use the logging macros from zotonic_core/include/zotonic.hrl when that header is already included. Branch on the actual result of the operation before logging success or failure.
Read logs and collect useful evidence
Access needed: Site log permission or server log access.
- Record the time, environment, hostname, affected page, and action that failed.
- Check the relevant site log or service log around that time.
- Identify the first relevant error and its module, request or correlation identifier, and repeated causes.
- Compare with the last deployment or configuration change.
- Reproduce once with safe test data when possible and note the expected and actual result.
- Share a short redacted excerpt and the reproduction steps with the responsible operator or developer.
Do not publish complete configuration dumps, cookies, authorization headers, password-reset URLs, or message bodies. Retain detailed logs in the controlled incident record.
More logging is not always better: temporary debug logging can expose data or fill disks. If enabled for diagnosis, record the change and turn it off afterwards.