List the three OpenTelemetry span status codes and what each means
UNSET is the default. OK is an explicit success claim. ERROR is the failure signal that alerts key on. Most spans stay UNSET.
Picture a stack of receipts at the end of a workday. Most receipts have no marking. They are just records that a thing happened. A few have a green check stamped on them by hand to say someone confirmed all was well. A few have a red cross stamped to say something went wrong. The pile of red-cross receipts is what the manager scans for. The unmarked pile is the bulk of the day. The green-cross pile is rare and only used when someone wanted to write down that they explicitly checked. Span statuses work the same way. The default is silence. You only stamp the receipt when you have a real reason to claim success or signal failure.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Span status is one of the smallest surfaces of the OpenTelemetry spec and one of the most consequential for production alerting. Get it right and your error-rate dashboards are honest. Get it wrong and either everything looks broken or nothing does.
This question is foundational because the three-value enum hides several non-obvious rules: the default is intentionally non-committal, exception recording does not mutate status, and the right policy for parent versus child spans is a deliberate design choice not enforced by the SDK.
The three values, formally
UNSET (value 0 in the enum) is the default that every span starts with and the value most spans end with. The spec defines it as 'the operation has been validated by an application developer or operator to have completed successfully, or the operation has not completed yet', in practice, it means no explicit verdict.
OK (value 1) is an explicit success claim that the application developer wrote into the code. The spec says implementations should NOT set OK automatically; it is reserved for cases where the application code wants to record an active positive verdict. In practice, you almost never need OK.
ERROR (value 2) is the failure signal. It is the value that error-rate panels in Langfuse, Phoenix, Datadog, and every other OTel-native backend count. ERROR carries an optional description string explaining what failed.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- OpenTelemetry SDK 1.x in Python, Node, and Java all expose StatusCode.ERROR / OK / UNSET on the Span interface.
- Langfuse maps OTel ERROR status to a red badge on the trace view; UNSET and OK both render as success.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you record an LLM API exception so both the trace UI and the error-rate alert pick it up?
Walk through record_exception plus set_status, and explain why both are needed.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Setting OK on every successful span manually. The spec says leave it UNSET unless your code has a specific reason to claim success.
60 second bullets to scan on the way to the call.
Name the three OpenTelemetry span status codes
Explain which is the default and why
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.