I'm seeking a way to generalize the way log levels are managed in my services. I have multiple services, written in multiple languages, and using multiple libraries to manage logs.

Almost all of them has its own choice for numerical and string representation of a log level, and they had different number of available levels (For example, see Java's Log4j, Python's logging, and JavaScript's Bunyan).

Suppose I want to use a log processor (e.g. Fluent-Bit) to forward all of these logs to a single source of log management (e.g. Graylog). The Graylog itself uses syslog severity levels to categorize received logs.

I'm currently converting all these log levels using a wrapper of those libraries to convert them to Syslog levels, but if I decided to migrate from Graylog in future, I have to change them all.

My questions are, isn't there any global standard for setting the log levels? If not, there shouldn't be? If not, why?

  • 1
    Error, warn, info and debug. That's about as close to a "standard" as I've ever found. Commented Jun 8, 2020 at 2:50
  • 3
    This is a valid question which was asked and answered already on Stackoverflow eight years ago, and that answer is, to my knowledge, still valid and probably the best you can get here. Hint: it took me one google search for "log level standard" to find that older question.
    – Doc Brown
    Commented Jun 8, 2020 at 6:22
  • 2
    ... and if you want to know why there is no better standard, step back for a moment and think of the universe of software around us, which different logging requirements different programs may have, and why it does not make much sense to seek a one-size-fits-all solution.
    – Doc Brown
    Commented Jun 8, 2020 at 6:28
  • @Doc Brown Thanks, I read that question before asking this one, took me one Google search too. I didn't get your second comment though, it doesn't seem that Python designed their logging library for specific requirements, while Java did that for another requirements.
    – Ali Tou
    Commented Jun 8, 2020 at 9:20
  • 3
    I mean, it's hard to not point out the relevant XKCD here.
    – Flater
    Commented Jun 8, 2020 at 9:54

2 Answers 2



Standardization often comes at the cost of less flexible tailoring, and logging is something where custom tailoring is often highly desirable.

Secondly, relevant XKCD.

My questions are, isn't there any global standard for setting the log levels?

There's a general convention about what differentiates e.g. an error from a trace message. However, the finer points are up for discussion, e.g. the distinction between a debug an trace message.

There is no hard and fast rule. What I suspect most (if not all) developer will agree with:

  • Error messages report failures
  • Warning messages report unusual (but non-failure) messages or messages where the log reader's attention is required (e.g. a license that's going to expire soon, a persistently slow network response)
  • Information messages don't require the log reader's focus but are relevant enough to always log (as opposed to debug messages)
  • Debug messages are messages that are relevant to developers but shouldn't be part of the regular (release) logging due to the data size or log file pollution it causes

Again, this is not a hard and fast rule, but these distinctions are my default expectation of any logging I encounter, and I hardly ever encounter any project that doesn't match these expectations.

If not, there shouldn't be?

This would just be another holy war. And in the end, it doesn't really matter as each project/company has its own expectations on what the logging should and shouldn't contain.

Standardization often comes at the cost of less flexible tailoring, and logging is something where custom tailoring is often highly desirable.

If not, why?

Because there's little purpose to having it. The goal of standardization is to either improve the runtime, code cleanliness or to make it more viable for new developers to adapt to this codebase. But log labeling doesn't really affect any of these considerations as it's just an arbitrary label you slap on a message.

  • The runtime performance is unchanged regardless of which label you slap on a log message.
  • The code structure is unaffected other than choosing this arbitrary log label
  • While the absence of logging can dramatically impact a new developer's experience, the label of the logging has less of an impact. Developers generally access the full logs when debugging (since debug is one of the lowest log levels by most conventions).

On top of that, not every project's logging needs require the same amount of log levels. For a larger enterprise applications, it makes sense to e.g. distinguish between fatal/error and debug/trace, but that distinction doesn't matter in a project the size of e.g. a commandline module.

Some application may even add several new log levels, e.g. distinguishing between an error message that should be accessible to the end user and those that shouldn't be. This is just a random example, but there can be myriad reasons why you'd decide to introduce an additional log level - and your standard would fly out the window when you're working with a different collection of possible log levels.


Yes. The Syslog Protocol, RFC 5424, specifices eight severity levels:

       Numerical         Severity
          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

These levels have been adopted or adapted for use in PHP as part of PSR-3 Logger Interface, and I believe also in many other contexts.

  • 1
    Labeling error as "error conditions" seems a bit tautological (same goes for warning/critical/informational), and the reference protocol page doesn't actually further define these".
    – Flater
    Commented Jun 8, 2020 at 12:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.