Trace and Event Log Severity Levels
Published: May 2010
When using the Unified Logging System (ULS) APIs to define events or trace logs, one of the values you must supply is the ULS level. Levels are settings that indicate the severity of an event or trace and are also used for throttling, to prevent repetitive information from flooding the log files. Use the following guidelines to determine the appropriate level to use for your scenario.
When defining an event in your Manifest.xml file, it is important that you choose an appropriate severity level. The severity level of an event is displayed in the Windows Event Log and is used by administrators and registered by monitoring tools to indicate how severe or important an event is. Choosing an appropriate level is a key part of the health and monitoring design for your component or system.
For more information about the event manifest schema, see Event Schema
ULS Level Name
Shown in Event Log as…
Events that demand the immediate attention of the system administrator. They are generally directed at the global (system-wide) level, such as System or Application. They can also be used to indicate that an application or system has failed or stopped responding.
Events that indicate problems, but in a category that does not require immediate attention.
Events that provide forewarning of potential problems; although not a response to an actual error, a warning indicates that a component or application is not in an ideal state and that some further actions could result in a critical error.
Events that pass noncritical information to the administrator, similar to a note that says: "For your information."
Verbose status, such as progress or success messages.
When writing a trace log by using the ULS API, you must specify a severity level. The severity level is displayed in the ULS trace log and is commonly used by reporting or filtering tools. For this reason, it is important to choose an appropriate level.
ULS Level Name
Similar to an Assert (an assumption in code that a condition is true at a particular point), this message indicates that a logic check failed that is atypical, or the message returns an unexpected error code. These generally represent code bugs that should be investigated and fixed.
Traces that indicate a problem, but do not need immediate investigation. The intent is to collect data and analyze it over time, looking for problem trends.
General functional detail, the high priority events that happen in the environment. Examples include global configuration modifications, service start and stop, timer jobs completed, and so on.
Useful to help support or test teams debug customer or environmental issues. These likely include messages indicating that individual features have succeeded or failed, such as creating a new list, modifying a page, and so on.
Useful primarily to help developers debug low-level code failures. Not generally useful to anyone who does not have access to source code or symbols. Most event tracing that does not need to be enabled all the time should be set at the Verbose level.
Useful for traces that are likely to be high volume, especially information that is not needed for all debugging scenarios. Examples of situations where you should use the VerboseEx setting are method entry and exit events, tracing in loops, or to relay information that is not useful to developers outside your team.