dbr-logs
Fetch and display Databricks job logs from Unity Catalog Volumes.
Merges driver and executor logs chronologically with source labels, so you can pipe them to grep, jq, or feed them to an LLM.
Why
Debugging a failed Databricks job means navigating a deeply nested, inconsistently structured log directory tree:
dbfs:/Volumes/catalog/schema/logs/prod/my-spark-job/0311-170011-t5450avl/
├── driver/
│ ├── stderr
│ ├── stderr--2026-03-11--18-00 # rotated, plain text
│ ├── stderr--2026-03-11--19-00 # rotated, plain text
│ ├── stdout
│ ├── log4j-active.log
│ └── log4j-2026-03-11-17.log.gz # rotated, gzipped
├── executor/
│ └── app-20260311170849-0000/ # opaque app ID
│ ├── 0/
│ │ ├── stderr
│ │ ├── stderr--2026-03-11--18.gz # rotated, gzipped
│ │ └── stdout
│ ├── 1/
│ ├── 2/
│ ...
│ └── 8/
└── eventlog/
The manual process to find what went wrong:
- Find the run — run IDs are opaque strings like
0311-170011-t5450avl, not human-readable
- Navigate the tree — driver logs, executor logs, or both? Which of the 9 executors had the error?
- Handle mixed compression — driver rotated files are plain text, executor rotated files are
.gz. You need to databricks fs cp + gunzip to read them
- Concatenate rotated files — a single stream is split across the active file and multiple rotated files that must be read in chronological order
- Repeat across executors — for a job with 9 executors, that's potentially 9 x 4 files to check
- Cross-reference timestamps — the root cause is often in one source, but the symptoms appear in another
For background on how Python logging works in Databricks and why it ends up in this structure, see Everything You Wanted to Know About Python Logging in Databricks.
There are heavier alternatives — Databricks' own Practitioner's Ultimate Guide to Scalable Logging describes a full logging pipeline, and you could also route Databricks logs to Datadog or similar observability platforms. But these solutions carry significant ongoing costs and infrastructure overhead for something most teams only need occasionally when debugging a failed job. dbr-logs is a zero-cost, zero-infrastructure alternative: install a CLI tool, run one command, get your answer.
dbr-logs replaces the manual process with a single command. It discovers the log structure, downloads and decompresses all files, merges everything chronologically with source labels, and lets you filter by level, source, or regex.
Prerequisites
- Python 3.11+ (tested on 3.11, 3.12, 3.13, 3.14)
- Databricks CLI configured with at least one profile in
~/.databrickscfg (setup guide)
- Unity Catalog Volumes log destination configured on your Databricks jobs (
cluster_log_conf pointing to a Volumes path)
Installation
# Install as a CLI tool with uv (recommended)
uv tool install dbr-logs
# Or with pipx (isolated environment)
pipx install dbr-logs
# Or with pip (use --user to install globally without affecting your venv)
pip install --user dbr-logs
# Or run directly without installing
uvx dbr-logs <job-name>
Usage
# Fetch logs for the latest run of a job
dbr-logs my-job-name
# Fetch logs from a specific run
dbr-logs my-job-name --run-id 12345
# Use a Databricks workspace URL
dbr-logs "https://dbc-xxx.cloud.databricks.com/jobs/12345/runs/67890?o=123"
# Show only errors
dbr-logs my-job-name --level ERROR
# Focus on application logs (suppress Spark/JVM noise)
dbr-logs my-job-name --focus
# Show only executor logs
dbr-logs my-job-name --source executor
# Show last 50 lines from a specific executor
dbr-logs my-job-name --source executor:3 --tail 50
# JSONL output for piping to jq
dbr-logs my-job-name --format jsonl | jq '.level'
# Logs since last hour
dbr-logs my-job-name --since 1h
Claude Code Integration
dbr-logs includes a Claude Code plugin so you can fetch and analyze logs directly from a Claude conversation.
Install the plugin
# Option 1: Claude Code Plugin
/marketplace add https://github.com/zencity/databricks-logs-reader
/plugin add dbr-logs
# Option 2: skills.sh (works with Claude Code, Cursor, Windsurf, etc.)
npx skills add zencity/databricks-logs-reader
The CLI tool still needs to be installed separately (pip install dbr-logs or uv tool install dbr-logs), but the skill can also use uvx as a zero-install fallback.
Example interaction
You: check the logs for my-spark-job
Claude:
Runs: dbr-logs my-spark-job --level ERROR,WARN --focus --format jsonl
Analyzes output, then responds: