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.
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.
Live, conversational lookups
Pair the Atlassian Rovo MCP server (Jira & Confluence) with the Metabase MCP server.
- Ad-hoc questions ("which sprint issues are still open?")
- Exploration before modeling
- 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.
Durable dashboards with history
Sync Jira into a database, then point Metabase at it.
- Durable dashboards, historical trends
- Joining Jira with deploys/support data
- 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/sseendpoint 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
# 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-mcpClaude Desktop: add each as a remote/custom connector (Settings → Connectors) using the same URLs; Claude handles the OAuth pop-up.
codex mcp add atlassian --url https://mcp.atlassian.com/v1/mcp/authv2
codex mcp add metabase --url https://your-metabase.example.com/api/metabase-mcpFirst 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"
[mcp_servers.metabase]
url = "https://your-metabase.example.com/api/metabase-mcp"{
"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.
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.
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:
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?
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.