Overview · Integrations

How do you analyze issue tracking data in Metabase?

Issue trackers like Linear and Jira hold the record of what your team plans, works on, and ships. To analyze them in Metabase, you sync the tool into a database, map its objects to a shared issue-tracking model, and build dashboards on top. Metabase has no native connector for these tools, so the sync comes first.

TL;DR — Most issue trackers share the same shape: issues, projects, cycles/sprints, statuses, labels, users, and change history. Model that shape once and most dashboards and metrics port across tools — only the source-specific fields differ.

Which tools does this cover?

This pattern applies to issue tracking and project management tools, including:

  • Linear — teams, cycles, projects, workflow states, labels, estimates
  • Jira — projects, boards, sprints, epics, issue types, statuses, resolutions, changelogs
  • GitHub Issues, Shortcut, ClickUp, Asana, Trello, Height (same shared model)

What is the shared issue-tracking data model?

Almost every tracker maps onto these entities. Model them as clean tables, not raw connector JSON:

ConceptLinear termJira termUsed for
IssueIssueIssueThe atomic unit of work
GroupingProjectProject / EpicScope and roll-ups
IterationCycleSprintVelocity, carryover
StatusWorkflow stateStatusFlow, time-in-status
TagLabelLabel / ComponentBug/support classification
PersonUserUserAssignment, load
Change logIssue historyChangelogCycle/lead time, scope change

The single most important field is a reliable status-change history. With it you can compute true cycle time, time-in-status, carryover, scope change, and reopen rate. Without it, those metrics must be caveated.

How do you connect an issue tracker to Metabase?

  1. MCP route (AI-assisted) — pair the tool's MCP server with the Metabase MCP server for fast, exploratory questions. Treat it as exploratory, not governed reporting.
  2. Pipeline route (warehouse-backed) — sync the tool into a database with Airbyte, Fivetran, dlt, or the API, then build durable dashboards.

See the per-tool setup on the Linear and Jira pages.

What can you analyze across issue trackers?

  • Throughput & velocity — items/points completed per iteration
  • Flowcycle time, lead time, WIP, time-in-status
  • Backlog health — backlog aging, unassigned/untriaged work
  • Quality — bug aging, bug inflow vs. resolution
  • Predictability — carryover, scope change, estimation accuracy

Which dashboards should you build?

Common mistakes

Treating tools as fundamentally different.→ 80% of the model is shared; standardize it.
Skipping the history table.→ Point-in-time snapshots can't reconstruct flow.
Inconsistent status mapping.→ Normalize many statuses into a small state_type set (backlog / started / completed / canceled).

Integrations

Dashboards

Metrics

FAQ

Can I use the same dashboards for Linear and Jira?
Mostly yes, if you model both onto the shared schema. Metric definitions and chart structure port across; only source-specific fields (e.g. Jira resolutions, Linear estimates) differ.
Do I need status history?
For throughput and open counts, no. For cycle time, time-in-status, carryover, scope change, and reopen rate, yes — sync the changelog/issue-history.
Is there a native Metabase connector for issue trackers?
No. Sync to a database first, then connect Metabase to that database.