Logging to debug the past, present, and future

When you’re deciding about logging (how, what, when, etc) it can be useful to think about time.

When you’ve been combing through logs in the past:

• What type of information was useful?
• Which were “spammy”?
• Which logs could have used additional context (for example, logging an event but not enough details for some relevant object)
• Are you retaining logs for long enough, in case you need to check on older ones?

When you are working with logs in the present:

• Can you clean up old logs that are no longer relevant?
• Are there logs that would be useful for what you are implementing right now?
• Are there error or warning logs that have started triggering that didn’t before?
• What is the performance and storage cost of your current logging? Is it under control?

When you are implementing for the future:

• Can you imagine yourself 6 months from now, and what kind of logs you’d hope to see? What do you think you’d need?
• Imagine you forgot all the details of the project. What are the key logs that would help you get up to speed?
• Are you able to readily retrieve the logs you need when your project is deployed? (for example, running on a consumer device)
• Is your logging compliant with the rules of your industry and/or platform? (no PII, uses appropriate APIs, etc)

These are a good start to logging more effectively, so you can debug better.