Three myths about application logging

The advice here is unglamorous, which is probably why it gets skipped. A few things about application logging that get repeated more often than they get checked.

The question is rarely whether something can be built, but what it costs to keep running afterwards. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

“It only matters for big sites”

Logs are what you have when something breaks at 2am. Getting it slightly wrong is survivable. Ignoring it entirely is not. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

“We can deal with it after launch”

Sometimes true, usually expensive. The cost of getting this wrong is rarely visible on the day it happens.

“Our platform handles it”

Never log passwords, tokens, or full card numbers. That sounds obvious written down. It is still the thing most often skipped. It is the sort of thing that looks like polish right up until it costs you an enquiry.

How to tell if yours is fine

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about application logging before you move on:

• Someone can say what the current setup is without going to look
• Logs are what you have when something breaks at 2am — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.