Bittensor Logging Levels
Bittensor logging levels are severity labels for diagnostic messages (Logging, Subtensor Error Codes).
They help readers distinguish detailed diagnostic output from normal status messages, successful events, warnings, errors, and critical failures.
Severity Ladder
The logging ladder runs from trace and debug through info, success, warning, error, and critical (Logging, Subtensor Error Codes).
The lower-detail levels help with normal status reading. More verbose levels can expose diagnostic detail, while warning, error, and critical messages point readers toward conditions that may need attention.
Each logging level has a numeric value
(Logging). NOTSET is 0, TRACE is
5, DEBUG is 10, INFO is 20, SUCCESS is 21, WARNING is 30, ERROR is 40, and
CRITICAL is 50.
Those numbers explain the ordering of the ladder. Trace sits below debug as the most verbose diagnostic level, while critical sits at the high-severity end for serious errors that may cause the program to abort (Logging).
The table also shows why success is placed between info and warning. It marks completion of an operation, but it is still below warning, error, and critical in severity (Logging).
Choosing Detail Level
The level also tells readers how much diagnostic detail they are seeing. Trace and debug messages are useful when the reader needs more detail about what the software is doing, while info and success messages are closer to normal progress reporting (Logging).
This helps keep noisy diagnostic output separate from messages that summarize expected progress or attention-worthy problems.
Level selection acts as a verbosity threshold: messages at or above the set level are logged (Logging). A higher threshold therefore hides lower-detail messages, while a lower threshold allows more diagnostic output to appear.
That threshold behavior is different from the meaning of a single message. Setting a more verbose level changes how much output is visible; it does not change whether the underlying event succeeded, failed, or needs a separate chain reference.
This is useful when reading logs from tools that can produce both routine progress messages and diagnostic detail. The selected level controls visibility, while the message text and surrounding context explain what the software is reporting.
Bittensor-Specific Levels
Bittensor adds trace and success to the standard logging ladder. Trace represents fine-grained diagnostic output; success marks an event that completed as expected (Logging, Introduction to Bittensor).
These additions make logs easier to scan without changing the core idea that the level describes how the software classified the message.
TRACE and SUCCESS are custom Bittensor levels
(Logging). Their numeric placement
shows how they fit into the ladder: trace expands the low-level diagnostic side, while success adds
a positive completion label just above ordinary info.
That means the custom labels are not separate log systems. They are additional severity labels inside the same ordered scale used to decide which messages appear.
Logs and Error Codes
Logging levels and Subtensor error codes answer different questions. A logging level describes message severity or verbosity; an error code identifies a rule family or failure category from the Subtensor layer (Subtensor Error Codes, Subtensor Standard Errors).
Reading them together can be useful. A log may point attention toward a failure, while the error code explains the Subtensor rule family involved.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. Bittensor logging examples should stay attached to the environment where they occurred (Bittensor Networks, Logging).
Localnet log examples can test diagnostics in isolation. Testnet examples add shared non-production network context. Mainnet logging interpretation concerns production Subtensor activity on the active network.
The level labels severity; the network context tells readers where the message belongs. A warning in a local run and a warning while connected to a shared network can deserve different follow-up.
Reader Boundary
Bittensor logging levels should be read as diagnostics vocabulary, not as complete chain-state proof, role guidance, or confirmation that a submitted action succeeded (Logging, Subtensor Error Codes).
A log level is a clue about message importance, not a complete account of what happened. The useful reading order is level, then message, then context. When the result of a chain action matters, readers should pair the log with the relevant error code, event, storage value, or transaction context rather than relying on the level alone (Logging, Subtensor Error Codes).
Console Colors Mark the Level Label
Official Logging documentation assigns each severity level a default console color when the level label is printed beside a message. Trace appears in magenta, debug in blue, info in white, success in green, warning in yellow, error in red, and critical with a red background.
Those colors are a scanning aid for terminal output, not a second severity system. The level name and its place on the ordered ladder still define how the software classified the message. Optional color tags inside the message body add inline emphasis without replacing the level label itself.
That separation keeps bright styling from being read as network proof. A green success label or red error styling shows how the process presented the line locally; it does not by itself confirm a finalized outcome on Glossary: Subtensor.
References: Logging, Subtensor Error Codes
Emoji Patterns Are Display Shorthand
The same official logging page lists short text patterns that render as emojis in console output, such as a checkmark pattern for completed steps or a warning pattern for caution cues. Those replacements happen inside the message body and are meant to make long diagnostic streams easier to scan visually.
An emoji cue does not create a new severity level. The logging level still states whether the software treated the line as routine progress, diagnostic detail, or something that may need attention, and the surrounding message text still carries the specific claim.
When a line looks strongly positive or alarming because of an emoji, the level label should still lead triage. Visual shorthand can highlight a phrase quickly, but it does not substitute for message text, network context, or a confirmed Glossary: Block record when the underlying action matters.
References: Logging, Introduction to Bittensor
Optional Log Files Preserve Classifications
Official SDK Environment Variables documentation describes optional recording of log messages to files in addition to console output. When that recording is enabled, the same severity labels that appeared during the run can be stored for later review rather than disappearing when the terminal session ends.
File persistence changes where a reader can inspect output, not how each line was classified at the time it was emitted. A saved warning line still names a warning-level diagnostic from that moment; archiving the text does not turn it into verified chain state on Glossary: Subtensor.
That distinction keeps log archives useful for troubleshooting timelines without upgrading them to authoritative records. Stored messages remain software-reported diagnostics until paired with the relevant network context and, when needed, Subtensor Error Codes or other chain-side evidence.
References: Environment Variables, Logging