Application logging for small teams

The advice here is unglamorous, which is probably why it gets skipped. Most advice about application logging assumes a team that does not exist at your size. Here is the version that does not.

Most development decisions are really maintenance decisions wearing a different hat. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

What to keep

Logs are what you have when something breaks at 2am. Where this goes wrong is almost never a lack of knowledge. Assume whoever inherits this will have half your context and none of your patience.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Getting it slightly wrong is survivable. Ignoring it entirely is not.

The practical version

Never log passwords, tokens, or full card numbers. This is the sort of thing that compounds, quietly, in both directions. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The short version

The question is rarely whether something can be built, but what it costs to keep running afterwards. 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.