What does an error report look like?

A good error report should answer not only the question of what broke, but also help establish where and under what conditions the problem occurred.

That's why, besides the exception message itself, you can send information such as the stack trace, request details, the user, the environment and additional application context.

Exception and stack trace

The most important part of an event is the exception. The error type and its message describe the problem, while the stack trace shows the execution path that led to it.

In practice, it's often the stack trace that lets you move from a general message to a specific place in the code.

Request information

If the error occurred while handling an HTTP request, the additional context can include the address, the method, the response status and other selected information related to the request.

This makes it easier to determine whether the problem is specific to an endpoint, a form, a page or an operation performed by the user.

User and context

Depending on the integration you use, you may also be able to send information about the user, along with your own tags and contextual data. This lets you answer questions such as: which user was affected by the error, which module the problem concerned, or in which environment it was detected.

When it comes to user data, it's always worth applying the principle of minimisation. Only send information that's genuinely needed for diagnosis.

Custom application data

If the standard context isn't enough, you can enrich the event with your own tags. For example, you can mark errors related to payments, a specific module or a deployment version.

feature = payments
environment = production
release = 1.4.0

Don't send secrets

Error monitoring shouldn't be a place to send passwords, tokens, API keys or full authentication credentials. Before sending data, it's worth checking that the integration isn't accidentally passing along sensitive information.