How do you build Jira analytics dashboards in Metabase?

Jira tracks projects, sprints, and issues across many teams. Metabase turns that into shared dashboards. This guide covers two complementary paths: a lightweight MCP + CLI route that pulls live data with the Atlassian Rovo MCP server and loads a CSV into Metabase with the Metabase CLI for quick analysis, and a durable pipeline route that syncs Jira into a database so you can build dashboards anyone can read.

How do you connect Jira to Metabase?

Most teams combine both routes: use the Atlassian Rovo MCP server and Metabase CLI route to pull live data and stand up a quick analysis, and the pipeline route for the dashboards teams depend on.

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 do you use the Jira MCP server with the Metabase CLI?

Pair the Atlassian Rovo MCP server with the Metabase CLI for fast, hands-on analysis. Atlassian hosts a first-party remote MCP server that looks up live issue and project data (Jira and Confluence); the Metabase CLI'supload command loads a CSV into Metabase and creates a ready-to-query table and model. For analysis, use a read-scoped token.

Example workflow

• Ask the Atlassian MCP which issues in the current sprint are still open, or list high-priority bugs with no assignee.
• Export the issues, sprints, and changelog you want to keep as CSVs.
• Run mb upload csv to load them into Metabase as tables and models, then build questions and dashboards on top.

Be honest about the limits

• The Atlassian MCP is great for live lookups — not for scheduled or audited velocity reporting.
• A CSV upload is a point-in-time snapshot; trend and velocity history still need a warehouse sync, or refresh with mb upload replace.
• Use a read-scoped Atlassian token so analysis can't trigger writes.
• mb upload csv needs an uploads database configured under Admin → Settings → Uploads.

How do you set up the Jira MCP server and the Metabase CLI?

# Atlassian Rovo (remote, OAuth in browser — covers Jira & Confluence)
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2

Claude Desktop: add Atlassian as a remote/custom connector (Settings → Connectors) using the same URL; Claude handles the OAuth pop-up.

codex mcp add atlassian --url https://mcp.atlassian.com/v1/mcp/authv2

First remote MCP in Codex? Enable the rmcp client in ~/.codex/config.toml:

[features]
experimental_use_rmcp_client = true

[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v1/mcp/authv2"

{
  "mcpServers": {
    "atlassian": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.atlassian.com/v1/mcp/authv2"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. On first connection the Atlassian server opens a browser window to authorize.

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a Jira CSV export — creates a table AND a model
mb upload csv --file jira-issues.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file jira-issues.csv

The Metabase CLI stores its credentials securely after mb auth login.

Can you generate a Jira dashboard with AI?

Yes. Use the prompt below with any assistant that can run the Atlassian Rovo MCP server and the Metabase CLI. It works end to end: if Jira tables already exist in Metabase it analyzes those; otherwise it pulls the data over the Atlassian MCP, loads it with mb upload csv, then builds the dashboard — skipping cards it has no data for.

Create a Metabase dashboard called "Jira Sprint & Delivery Health".
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help engineering and product leaders understand sprint health,
throughput, flow, and defect load from Jira data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Jira tables and
  models). If durable Jira data is already present — synced from a warehouse or
  uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull it with the Atlassian Rovo MCP server using a
  read-scoped token: issues, sprints, projects, the issue changelog, and users.
  Write each result to a CSV, then load it with the Metabase CLI — run
  "mb upload csv --file <export>.csv" so each upload creates a table and a
  ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv"
  to refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Do not assume table names. Map the available raw tables into these analytical
concepts where possible: issues, sprints, projects, issue_changelog, users.
Normalize workflow statuses into To Do / In Progress / Done. Inspect the actual
tables and column names first; story points are usually a custom field that
differs per site.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Jira — it reads a database or CLI-uploaded tables.
- Only compute cycle time, time-in-status, and scope change if issue_changelog
  exists; otherwise add a caveat.
- Only build a card if its underlying column/metric exists in the data.
- A single CSV is a point-in-time snapshot: velocity and flow trends need a
  warehouse sync or multiple uploads, so build trend cards only if that history
  is present.

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.

Filters: project, board, sprint, issue type, priority, assignee, and date
range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
build durable models from the database tables.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data. Keep it practical, dense,
and executive-readable. Avoid vanity metrics.

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_changelog if you want accurate cycle/lead time — a single resolved timestamp loses transitions.
• Map your instance's custom fields (like story points) explicitly.

How should you model Jira data in Metabase?

Map Jira's objects to a clean model (don't report off raw connector tables):

• 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.

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?

Related

Integrations

Dashboards

Metrics

FAQ