Tracking URI and Storage
Where did my run go?
It's entirely possible to log runs correctly and still lose track of them, because MLflow needs to be told where to actually store and later retrieve that data. That destination is called the tracking backend, and you point MLflow at it with a Uniform Resource Identifier (URI) - a standardized way of writing "where something lives." A local-file URI might look like file:///home/labuser/workspace/mlruns; a server-backed URI would instead start with http:// and point at a running MLflow tracking server.
The trap that catches a lot of beginners: a relative path like ./mlruns (without a leading file:// and full path) means something different depending on which directory your script happens to be run from. Run the exact same script from two different working directories and you can end up with two entirely separate, disconnected sets of runs, each thinking it's the only one - the missing runs aren't lost, they're just sitting in a different folder than you're looking in.
$ export MLFLOW_TRACKING_URI="file:///home/labuser/workspace/mlruns"
$ mlflow experiments search
Experiment Id Name Artifact Location
1 chunk-size-sweep file:///home/labuser/workspace/mlruns/1
$ mlflow runs list --experiment-id 1
Run Id Status Start Time
8f2a1c... FINISHED 2026-08-30 10:14:02The fix is to be explicit rather than relying on defaults: set the MLFLOW_TRACKING_URI environment variable, or call mlflow.set_tracking_uri() at the very start of your script, before creating or using any experiment. You can then confirm everything landed where you expect using exactly the same URI with mlflow experiments search and mlflow runs list, as shown above.
Warning: A script exiting with no errors is not proof that central tracking actually worked - it may have quietly written to a different local mlruns folder than the one your team is looking at. Always verify by explicitly querying the expected backend for the run you just logged and confirming the fields you expect are actually there.