Integration · Issue tracking

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.

Heads up: Jira's data model is richer (and messier) than most trackers — custom fields, multiple issue types, configurable workflows, and per-project schemes. Standardize it in a model layer before you report.

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):

TableGrainKey columns
issuesone row per issueid, key, project_id, issue_type, status, status_category, priority, story_points, assignee_id, epic_id, sprint_id, resolution, created, resolved
sprintsone row per sprintid, board_id, name, state, start_date, end_date, complete_date
projectsone row per projectid, key, name, lead_id
issue_changelogone row per field changeissue_id, field, from, to, changed_at
usersone row per useraccount_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 single resolved timestamp for flow.
  • Map story_points from 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.

No paid tool required. A fully free stack: a small dlt or hand-written script (extract) → a free Postgres database like Neon or Supabase (load) → a scheduler such as GitHub Actions cron (host) → Metabase (visualize). For hosting and scheduling details, see our data pipeline guide.

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_changelog if you want accurate cycle/lead time — a single resolved timestamp 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:

ClaudeClaude Code CLI
# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp
Cursor~/.cursor/mcp.json or .cursor/mcp.json
{
  "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 & authenticateshell
# 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 status

On 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:

Prompt for a Jira Sprint & Delivery Health 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?

Sprint velocity (committed vs. completed points)PostgreSQL
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;
Open bugs by priorityPostgreSQL
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?

Reporting off raw connector schema.→ Model a clean layer; Jira's raw tables are deeply nested.
Trusting resolved for cycle time.→ Reopened/transitioned issues need the changelog.
Hard-coding a story-points field.→ It's a custom field that differs per site; map it explicitly.
Mixing status categories across projects.→ Normalize to To Do / In Progress / Done.
Averaging durations.→ Use median and p90.

Integrations

Dashboards

Metrics

FAQ

Does Metabase have a native Jira connector?
No. Sync Jira into a database (Airbyte, Fivetran, dlt, or the REST API), then connect Metabase to that database.
How is this different from Jira's built-in reports?
Metabase lets you join Jira with other sources (deploys, support, source control), define metrics once, and share governed dashboards across the org.
Can I compare Jira and Linear in one dashboard?
Yes — model both onto the shared issue-tracking schema and union them.