Logs are easiest to add when something is already broken. That is also when teams are tired, rushed, and likely to log the wrong thing. A better approach is to decide what product moments deserve evidence before the incident.
Good default logs make future explanations cheaper.
Log decisions
Capture why the system chose a path: eligibility checks, rate-limit decisions, plan permissions, fraud rules, routing choices, and fallback behavior. Event logs say what happened. Decision logs say why.
That distinction matters when support asks why two users saw different outcomes.
Avoid private data as a shortcut
Logs should be useful without becoming a shadow database. Prefer stable IDs, status names, rule identifiers, and counts over raw messages or personal data. If a sensitive value is required, document why and how long it is retained.
Debuggability should not quietly become a privacy problem.
Give logs a reader
Every important log should have an expected reader: engineer, support, security, finance, or customer success. That reader shapes the fields and the wording. A log nobody can interpret is just storage cost with timestamps.
Log for the person who will be awake later.
