What to log and what to ignore
Logging everything is the same as logging nothing, the signal drowns. Good logging is a series of deliberate choices.
There are two failure modes in logging: too little, so you’re blind when something breaks, and too much, so the one useful line is buried under a million routine ones. Both leave you unable to answer the question that matters: what happened?
Log for the future investigation
The point of a log is to reconstruct what happened when you weren’t watching. So log the things you’d want to know during an incident: decisions made, inputs received, errors hit, boundaries crossed. Skip the noise that never helps anyone.
Make logs usable
A useful log is structured and searchable, with enough context on each line to mean something on its own. 'Error' tells you nothing; 'failed to charge order 1234: card declined' tells you everything. Quality of logging beats quantity every time.
Logging everything is just noise with a timestamp. Log what you’d want during the 2am incident, nothing more.