Retrieving MLflow Traces
Bound Unity Catalog Searches by Time
When searching traces stored in Unity Catalog, include trace.timestamp_ms >= <start_time_ms> in the filter string, with an upper bound when known. This also applies when searching by experiment ID, run ID, session, or other filters: a small result limit does not prevent a scan across the full trace history. In Python, pass the time condition through filter_string; mlflow.search_traces() has no start_time argument.
Use the time window requested by the user or established by the run or incident. For setup verification, record the time immediately before the instrumented run. Do not silently restrict historical investigations to the last hour. If the relevant period cannot be determined, ask for it before starting a broad UC search. The examples below demonstrate individual filters; combine them with the relevant time bounds for UC.
Keep Setup Verification Brief
For verifying newly added instrumentation, follow the verification workflow in instrumenting-with-mlflow-tracing. Enforce a 60-second wall-clock deadline for readback, cancelling the verification command at the deadline even if a call is still retrying internally: make one fetch by a known trace ID, or one time-bounded search with --max-results 1 (Python: max_results=1). Retry at most once after a concrete, quick fix, within the same budget. Stop once one trace and its expected spans are confirmed.
If readback is slow or fails, report what was verified, what remains unverified, and the observed blocker and required user action (such as configuring a missing API key, logging in, obtaining permission, or resolving warehouse availability/capacity). Do not start parallel searches or fall back to direct SQL, raw REST, alternate authentication, or repeated agent runs just to complete setup verification. A dedicated retrieval or debugging request can require broader investigation; preserve the user's scope.
Single Fetch vs Search
Choose the right approach based on what you have:
Single fetch - Use when you have a specific trace ID (e.g., from UI, logs, or API response):
Search - Use when you need to find traces by criteria (session, user, status, time range, etc.):
Trace Data Structure
- TraceInfo:
trace_id,status(OK/ERROR),timestamp_ms,execution_time_ms,tags,metadata,assessments(human feedback, evaluation results) - Spans: Tree of operations with
name,type,attributes,start_time,end_time
Workflow
- Check CLI usage (required):
mlflow traces search --help - Build filter query using syntax below
- Execute search with appropriate flags
- Retrieve details for specific traces if needed
Prerequisite: Check CLI Usage
Always run this first to get accurate flags for the installed MLflow version.
Searching Traces
The mlflow traces search command is used to search for traces in an MLflow experiment.
By Run ID
Filter traces associated with a specific MLflow run:
By Session or User (Common for Debugging)
When debugging an issue from the MLflow UI, filter by session or user ID to get all related traces:
By Status
By Time Range
By Execution Time (Slow Traces)
By Tags and Metadata
By Assessment/Feedback
Full Text Search
Pagination
Control result count and iterate through pages:
Output Options
Retrieving Single Trace
When you need to retrieve details about a specific trace, use the mlflow traces get command.
Filter Syntax
For detailed syntax, fetch from documentation:
Common filters:
trace.status: OK, ERROR, IN_PROGRESStrace.execution_time_ms,trace.timestamp_ms: numeric comparisonmetadata.\mlflow.trace.session`,metadata.`mlflow.trace.user``: session/user filteringtag.<key>,metadata.<key>: exact match or patternspan.name,span.type: exact match or patternfeedback.<name>,expectation.<name>: assessments
Pattern operators: LIKE, ILIKE (case-insensitive), RLIKE (regex)
Python API
For mlflow.search_traces(), see: https://mlflow.org/docs/latest/genai/tracing/search-traces.md


