Log Level Hierarchy

A look into the hierarchy of log levels in Software Engineering. What they mean, as well as some practical use cases.
Monitoring is an essential part of quality software engineering. It helps us know if and when something goes wrong in our software.
In the case something goes wrong; if we know where to look, we can find out what is wrong; debugging and troubleshooting will become a hundred times easier — this is where logging comes in.
Every good programming language/framework has support for logging. If you’re reading this article, chances are, you wish to find out what log level to use when logging out certain information.
In this article, we’ll take a look at the entire hierarchy, learn what each level means, as well as some appropriate use-cases.
Log Level Order
- Trace
- Debug
- Information
- Warning
- Error
- Critical (or Fatal)
What Each Log Level Means
Before delving further, it is important to know that an application will log out anything falling above, or matching the set loglevel.
Trace
This log level captures all the details about an application. Trace is mostly used to identify issues with a program. This level is ideal when you need to see what happened in your program or perhaps, identify what happened in a third-party library you used. Trace ideally shows every single step in an algorithmic process.
Debug
This level is a bit higher up the hierarchy than Trace. Think of this, as showing the result of some crucial computation. When something goes wrong, this is the level most developers will look, so be sure to log out the results of crucial computations and steps here. If something could potentially go wrong, a good practice, is to log out statements before and after the step, at Debug level.
Information
This is the standard log level. At this level, we generally give updates about state changes in an application. While it’s difficult to draw a fine line between Debug and Information levels, a good rule of thumb in deeming something fit for the Information level, is if they are not things to be worried about. A good fit for an information-level log, will be logging out a message, when a record is saved in a database, or when a request is received in an API Controller, or a response is returned.
Warning
This level is used to show when you have detected something not usual about the application, but at the same time is not an error, neither is it fatal to the program. This could include things like an out-of-date library, or a vulnerability with a package.
Error
At this level, developers will be able to view the exception messages their applications and programs encountered. As not all exceptions are fatal for a program, at this level, we want to log the non-fatal exceptions. Examples of this may include “ArgumentException”, “ValueException”, “NullPointerError”, etc.
Critical (or Fatal)
This is the highest log level. Here, all the developers would see, are the reasons an application or program exited unexpectedly. This may be when the operating system manually closes a program, or a user manually closes a program abruptly.
Till next time, compadre!

Tomisin Abiodun
Senior Software Engineer @ Checkout.com
I bridge code and product strategy to build scalable, human-centric products with strong AI, design, frontend, and cloud expertise.