Application Logging for Normal Users

Let’s say you’ve built an outstanding application. It’s robust, does its job well, and people love it.

But sometimes things go wrong. That’s okay! Your application has a great, searchable logging backend that lets you diagnose and fix problems as they happen.

Sounds perfect right? The problem is that developers don’t often sit around and watch logs for errors. We might check every now and again or studiously ignore alert emails, but it’s not something that’s part of our daily routine.

Ideally we’d want users to know when their processes went wrong so they can alert you, the developer, and get things resolved.

The problem is the average user doesn’t need to see real logging. — they don’t need exception names or technical sounding messages. In fact, those things might confused them.

There’s an alternative, however, and it’s very simple.

Give each error a unique identifier (like a uuid), show that error ID to the user with a generic something went wrong message in your application’s UI. Your real logging system will include that unique identifier.

This is not a new idea. The JSON API spec recommends something similar.

The goal here is to put the ball in the user’s court and give them the tools to help you solve the underlying problem. An error ID is a great way to do that: you can track down a single, specific log message whether it’s an application error or a simple misconfiguration.