Skip to content
Home » Logging Service levels – How it should be in Your Application

Logging Service levels – How it should be in Your Application

Logging Service Objective:

  • Logging in an application should not be just for the sake of logging so it should not lack coverage, consistency, and purpose. It should be the center point of any functionality.
  • A good/proper logging implementation tells the story of what happened through your application execution and provides the right amount of detail to understand why the course of execution and result took place.
  • Some areas of the application which behave more dynamically will require more logging then other more straightforward functionality so storing too much logging information is just as bad as storing too little because both scenarios prevent us from quickly drilling down to the root cause of problems when it is encountered.
  • Code which behaves differently based on incoming data is a prime candidate for more logging, while areas which do simple CRUD operations will require less.
  • A good example would be the number of records changed when pulling in data from an integration APIs.

Log Levels:

  • Software development has standardized on log levels. Below are levels listed in order of detail and frequency recorded.
  • Generally, an application should record INFO and lower (INFO, WARN, ERROR, FATAL) messages.
  • DEBUG and TRACE should be able to be enabled via configuration when necessary as this kind of logging will be temporary for debugging the code when problems are encountered.
  • The logging client should filter messages sent to the logging queue based on the configured log level.




It is the lowest possible rank. Intended to turn ON all logging including custom levels logging.


Designates finer-grained informational events than the DEBUG.


Designates fine-grained informational events that are most useful to debug an application.


Designates informational messages that highlight the progress of the application at coarse-grained level.


Designates potentially harmful situations.


Designates error events that might still allow the application to continue running.


Designates extremely severe error events that will presumably lead the application to abort.


The highest possible rank. It is intended to turn off the logging completely.

  • It should include a detailed execution flow, including applicable local variables, if/then decisions etc.
  • Logging at this level is primarily for isolating cause after the problem area of code has been identified and should be turned off once the problem is fixed.


  • The debug level will be enabled by developers in response to problems to diagnose issues.
  • Logging should include entry and exit points into methods, including input parameter values and returned responses.
  • It may need to run for an extended period of time in this mode but should be turned off once the issue is identified and fixed.
  • The purpose of this level is to explain why things happen.


  • This debug level is intended to tell the story of execution flow through the application.
  • It should not log variable values here. Here it should log major method entry/exits such as controllers, public model and library methods, and so on.
  • The purpose of this level is to explain what is happening, not why.


  • This is the lowest of error levels.
  • Here, we log issues which are correctable and do not impact execution but is not the expected behavior.
  • Things like missing data (which we can default around) or configuration roadblocks that prevent execution, security issues such as an unauthenticated user attempting something, and so on. These are items which need to be addressed, but don’t necessarily create a failure condition.


  • This error level demands attention.
  • Logging at this level should record whenever we encounter a trapped exception.
  • This should be anywhere we have a try..catch block kind of code.
  • This error level assumes we’ve trapped the error, stopped the execution, and responded to the user (or calling operation) but the code didn’t do what it intended to.


  • These are critical runtime errors and errors at this level demand immediate attention.
  • PHP/Node runtime errors which stop execution immediately should be recorded at this level.
  • Its likely errors logged at this level will trigger SNS(Simple Notification Service) notifications to the responsible parties to get an instant alert so as to fix it ASAP.


Leave a Reply

Your email address will not be published. Required fields are marked *