How do you build Jira analytics dashboards in Metabase?
Jira tracks projects, sprints, and issues across many teams. Metabase turns that into shared dashboards. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync Jira into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector. For the shared approach across tools, see the issue tracking overview; for a side-by-side alternative, see Linear.
How do you connect Jira to Metabase?
Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Jira connector. So connecting Jira to Metabase means one thing: run a small pipeline that copies Jira data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.
The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.
What can you analyze from Jira data in Metabase?
- Velocity & throughput — issues/story points completed per sprint
- Sprint health — committed vs. completed, spillover
- Cycle time & lead time — from status changelog
- Status flow & time-in-status — where issues wait
- Epic & project progress — scope vs. completion
- Bug & defect load — by priority, component, fix version
- Resolution analysis — Done vs. Won't Do vs. Duplicate
Which Jira dashboards should you build in Metabase?
- Sprint health — committed vs. completed points, spillover → see sprint health.
- Delivery overview — throughput, cycle time, bug load → see software delivery.
- Epic/project progress — % complete vs. target, scope change.
- Defect tracking — bugs created vs. resolved, open bugs by priority/component.
How should you model Jira data in Metabase?
Map Jira's objects to a clean model (don't report off raw connector tables):
| Table | Grain | Key columns |
|---|---|---|
issues | one row per issue | id, key, project_id, issue_type, status, status_category, priority, story_points, assignee_id, epic_id, sprint_id, resolution, created, resolved |
sprints | one row per sprint | id, board_id, name, state, start_date, end_date, complete_date |
projects | one row per project | id, key, name, lead_id |
issue_changelog | one row per field change | issue_id, field, from, to, changed_at |
users | one row per user | account_id, display_name, active |
- Normalize many workflow statuses into
status_category(To Do / In Progress / Done). - Derive cycle/lead time from
issue_changelog; don't trust a singleresolvedtimestamp for flow. - Map
story_pointsfrom whatever custom field your instance uses — it varies per site. - Treat components, labels, and fix versions as bridge tables.
How do you build the Jira → Metabase pipeline?
For dashboards that need history and reliability, land Jira data in a database first, then connect Metabase to that database.
Connector options
- dlt (free, code) — wrap Jira's REST API in a small Python pipeline for incremental, no-vendor loads. The lightest path to a maintainable sync.
- Jira REST API (free, raw) — write your own script that paginates issues, sprints, projects, and the changelog and upserts on a schedule.
- Airbyte — has a Jira source connector; free if you self-host the open-source version, paid on Airbyte Cloud.
- Fivetran (paid, managed) — a maintained Jira connector with incremental syncs and zero maintenance.
Notes
- Land raw tables first, then build clean models on top.
- Sync the
issue_changelogif you want accurate cycle/lead time — a singleresolvedtimestamp loses transitions. - Map your instance's custom fields (like story points) explicitly.
Can you generate a Jira dashboard with AI?
Yes — and once Jira data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.
Two ways to let an assistant query and build in Metabase
Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:
Metabase MCP
- Best for
- Chat clients (Claude, Cursor, Codex)
- Enable
- Admin → AI → MCP
- Endpoint
https://<your-metabase>/api/metabase-mcp- Auth
- OAuth handled by Metabase
Metabase CLI
- Best for
- Terminal agents, scripts, and CI
- Install
npm install -g @metabase/cli- Auth
- Browser OAuth (v62+) or an API key
- Docs
- @metabase/cli
Set up the Metabase MCP server
Enable it under Admin → AI → MCP, then point your client at the endpoint:
# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp{
"mcpServers": {
"metabase": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
}
}
}Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.
Set up the Metabase CLI
Install it globally, then authenticate once (the binary is mb):
# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli
# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth statusOn Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.
Prompt: build the Jira Sprint & Delivery Health dashboard
With MCP or the CLI connected, paste this into your assistant to generate the dashboard:
Create a Metabase dashboard called "Jira Sprint & Delivery Health" from the
synced Jira tables in this database. Inspect the schema first; do not assume
table names. Map raw tables to: issues, sprints, projects, issue_changelog,
users. Normalize workflow statuses into To Do / In Progress / Done.
Sections: (1) Sprint health — committed vs completed story points, spillover;
(2) Throughput — issues/points done per sprint, by team; (3) Flow — median
cycle time by week from the changelog, time-in-status; (4) Quality — bugs
created vs resolved, open bugs by priority and component.
Only compute cycle time, time-in-status, and scope change if issue_changelog
exists; otherwise add a caveat. Build durable questions from database tables
and do not claim a native Jira connector. Add filters for project, board,
sprint, issue type, priority, assignee, and date range.What SQL powers Jira dashboards in Metabase?
SELECT
s.name AS sprint,
s.start_date,
SUM(i.story_points) FILTER (WHERE i.sprint_id = s.id) AS committed_points,
SUM(i.story_points) FILTER (WHERE i.status_category = 'Done' AND i.resolved <= s.complete_date) AS completed_points
FROM sprints s
JOIN issues i ON i.sprint_id = s.id
GROUP BY s.name, s.start_date, s.complete_date
ORDER BY s.start_date;SELECT i.priority, COUNT(*) AS open_bugs
FROM issues i
WHERE i.issue_type = 'Bug'
AND i.status_category <> 'Done'
GROUP BY i.priority
ORDER BY open_bugs DESC;What are common mistakes when analyzing Jira in Metabase?
resolved for cycle time.→ Reopened/transitioned issues need the changelog.