It's good to have concrete definitions of what the error levels mean. It's also nice to eliminate as much as possible from live logs.
On a previous project we defined "Error" the same way, but we defined "Warning" a bit differently. We said that warnings are conditions are conditions that if they occur sometimes are okay, but if start appearing frequently, or too many at a time, are a problem.
We used those to mark code paths that were inefficient, or fallbacks to preferred algorithms. Something we'd expect to come up a couple of a times of day due to the operating environment. If they happened often it meant they were causing a significant problem for the tool.
Thanks for the comments.
We have toyed with the idea of adding a "wakeMeIfThisHappensTooOften" method to the logger to cater for that use case. The hard question is what means "too often".
In practice we have found that most times the places have this use case are protected by a circuit breaker so monitoring the circuit breaker is enough.
I would avoid having that couple of alerts every day if they are systematically ignored. One day they are two, next day they are four, ... One of the last projects that I worked at ended up with 13000 of those alerts which prompted me to write this blog post
We’re a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.