A short guide to application logging

It comes up on almost every project, usually later than it should. Everything we would tell a client about application logging in the time it takes to drink a coffee.

Most development decisions are really maintenance decisions wearing a different hat. Check it against what you would want a competitor's site to get wrong.

Why it matters

Logs are what you have when something breaks at 2am. There is a version of this that is over-engineered, and it is worth avoiding. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What good looks like

Structure them so they can be searched, not just read. In practice this is a scheduling problem more than a technical one. Budget a little time for it every quarter and it never becomes a project of its own.

Common failure modes

Never log passwords, tokens, or full card numbers. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

How to tell if yours is fine

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
• Structure them so they can be searched, not just read — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.