Integration · Issue tracking

How do you build Jira analytics dashboards in Metabase?

Jiratracks projects, sprints, and issues across many teams. Metabase turns that into shared dashboards. As with any tracker, Metabase reads SQL databases — there's no native Jira connector — so durable dashboards start with a sync. 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?

Most teams combine these: use the MCP route to explore and answer one-off questions, then build durable, warehouse-backed dashboards for anything you track over time. Setup for both MCP servers is below.

1 · MCP route (AI-assisted)

Live, conversational lookups

Pair the Atlassian Rovo MCP server (Jira & Confluence) with the Metabase MCP server.

Best for
  • Ad-hoc questions ("which sprint issues are still open?")
  • Exploration before modeling
Trade-offs
  • Exploratory only — not governed reporting; no history
  • API rate limits and Jira permission scopes apply
  • An admin must enable the Remote MCP server per-site (Rovo on); OAuth uses Dynamic Client Registration.
2 · Pipeline route (warehouse-backed)

Durable dashboards with history

Sync Jira into a database, then point Metabase at it.

Best for
  • Durable dashboards, historical trends
  • Joining Jira with deploys/support data
Trade-offs
  • You maintain the sync and model
  • Custom fields require mapping

How do you use the Jira and Metabase MCP servers together?

Pair the Atlassian Rovo MCP server with the Metabase MCP server for live, conversational analysis. The Atlassian MCP pulls current issue and project data (Jira and Confluence); the Metabase MCP queries the models and dashboards you've already built.

Example workflows

  • List issues in the current sprint via the Atlassian MCP, then summarize by assignee.
  • Pull a project's open bugs from Jira and cross-check progress against a Metabase model with the Metabase MCP.
  • Draft a SQL question in Metabase from a natural-language ask, using Atlassian MCP output to confirm what custom fields mean.
  • Triage: "show high-priority bugs with no assignee created this week" straight from Jira — no dashboard required.

Be honest about the limits

  • MCP is great for live lookups — not for scheduled or audited reporting.
  • It does not create history; trend and velocity analysis still needs synced data in a database.
  • Respect Jira API rate limits and project permission scopes.
  • An admin must enable the Remote MCP server per-site (Rovo on); OAuth uses Dynamic Client Registration, and the old /v1/sse endpoint is deprecated.
  • The Metabase MCP server is built in; an admin enables it under Admin → AI → MCP.

How do you set up the Jira and Metabase MCP servers?

Atlassian Rovo MCP official

Endpoint
https://mcp.atlassian.com/v1/mcp/authv2
Transport
Streamable HTTP
Auth
OAuth 2.1 with Dynamic Client Registration (browser); API token optional
Scope
Covers Jira and Confluence on your Atlassian Cloud site
Note
An admin enables it per-site (Rovo on); the old /v1/sseendpoint is deprecated.

Metabase MCP built-in

Enable
Admin → AI → MCP
Endpoint
https://<your-metabase>/api/metabase-mcp
Auth
OAuth handled by Metabase
ClaudeClaude Code CLI
# Atlassian Rovo (remote, OAuth in browser — covers Jira & Confluence)
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2

# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp

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

CodexOpenAI Codex CLI
codex mcp add atlassian --url https://mcp.atlassian.com/v1/mcp/authv2
codex mcp add metabase --url https://your-metabase.example.com/api/metabase-mcp

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

~/.codex/config.toml
[features]
experimental_use_rmcp_client = true

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

[mcp_servers.metabase]
url = "https://your-metabase.example.com/api/metabase-mcp"
Cursor~/.cursor/mcp.json or .cursor/mcp.json
{
  "mcpServers": {
    "atlassian": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.atlassian.com/v1/mcp/authv2"]
    },
    "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. On first connection each server opens a browser window to authorize.

Verify before shipping: endpoints and flags change — confirm the Metabase MCP URL in Admin → AI → MCP (Metabase docs) and the current Atlassian MCP details in the Atlassian Rovo MCP docs.

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.

Can you generate a Jira dashboard with AI?

Yes. Use this prompt with the Metabase MCP server plus an assistant that can read your warehouse schema:

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,
treat MCP as exploratory, 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.