Application logging: the questions we get asked most

The version of this that works is simpler than the version most people imagine. The questions about application logging that come up most often on our calls.

The question is rarely whether something can be built, but what it costs to keep running afterwards. Budget a little time for it every quarter and it never becomes a project of its own.

Do we need to care about this?

Logs are what you have when something breaks at 2am. In practice this is a scheduling problem more than a technical one. Check it against what you would want a competitor's site to get wrong.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The reasoning matters more than the rule, because the rule has exceptions.

How do we know it is working?

Never log passwords, tokens, or full card numbers. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

In practice

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

Pick the one that would hurt most if it failed, and start there.