npx claudepluginhub zencity/databricks-logs-readerFetch and analyze Databricks job logs from Claude Code
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.
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:
0311-170011-t5450avl, not human-readable.gz. You need to databricks fs cp + gunzip to read themFor 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.
~/.databrickscfg (setup guide)cluster_log_conf pointing to a Volumes path)# 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>
# 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
dbr-logs includes a Claude Code plugin so you can fetch and analyze logs directly from a Claude conversation.
# 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.
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: