How to build Linear analytics dashboards in Metabase

# Linear (remote, OAuth in browser)
claude mcp add --transport http linear https://mcp.linear.app/mcp

codex mcp add linear --url https://mcp.linear.app/mcp

[features]
experimental_use_rmcp_client = true

[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.linear.app/mcp"]
    }
  }
}

# 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 Linear CSV export — creates a table AND a model
mb upload csv --file linear-issues.csv --collection root

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

Create a polished Metabase dashboard for Linear analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help engineering and product leaders understand delivery health, cycle
progress, backlog risk, and bug/support load from Linear data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Linear tables and
  models). If durable Linear 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 Linear MCP server using a read-scoped
  connection: issues, teams, projects, cycles, workflow states, labels, users,
  and issue history / status-change events if available. 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 exact table names. Map the available raw tables into these
analytical concepts where possible: Issues, Teams, Projects, Cycles, Workflow
states, Labels, Users, and Issue history / status-change events if available.
Inspect the actual tables and column names first.

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

Dashboard title: Linear Delivery Health

Sections:
1. Executive summary (KPI cards): Open issues; Issues completed last 7 days;
   Issues created last 7 days; Median cycle time (only if a reliable
   started_at/status-history field exists); High-priority open bugs; Active
   projects at risk (only if project target/status fields exist).
2. Delivery throughput: Completed issues by week; Created vs completed by week;
   Completed issues by team; Completed issues by priority.
3. Cycle health: Current cycle planned vs completed; Incomplete issues by team
   and cycle; Carryover rate (only if cycle timing/snapshots exist); Scope added
   after cycle start (only if issue-cycle history/snapshots exist).
4. Project health: Active projects by status; Open issues by project and
   workflow state; Projects with target dates in next 30 days; Past-due/blocked
   projects (if fields exist).
5. Backlog and aging: Open backlog by team; Open issues by workflow state;
   Oldest open issues table; Unassigned/untriaged issues.
6. Bug and support load: New bugs by week; Resolved bugs by week; Open
   high-priority bugs by age; Bug/support issues by product area or label
   (use labels to identify bugs/support/customer requests if available).

Filters: Team, Project, Cycle, Label, Priority, Workflow state, Assignee,
Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_linear_issues, modeled_linear_teams,
modeled_linear_projects, modeled_linear_cycles, modeled_linear_workflow_states,
modeled_linear_labels, and modeled_linear_issue_events (only if history exists).

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.

Issues completed in each cycle, by team.

SELECT
  t.name        AS team,
  c.number      AS cycle,
  c.starts_at,
  COUNT(*)      AS issues_completed,
  SUM(i.estimate) AS points_completed
FROM issues i
JOIN cycles c ON c.id = i.cycle_id
JOIN teams  t ON t.id = i.team_id
WHERE i.state_type = 'completed'
GROUP BY t.name, c.number, c.starts_at
ORDER BY c.starts_at;

Flow trend using the median of completed_at − started_at.

SELECT
  date_trunc('week', i.completed_at)            AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (i.completed_at - i.started_at)) / 86400.0
  )                                             AS median_cycle_days
FROM issues i
WHERE i.state_type = 'completed'
  AND i.started_at IS NOT NULL
GROUP BY 1
ORDER BY 1;

Snapshot of open work right now.

SELECT
  i.state            AS state,
  COUNT(*)           AS open_issues
FROM issues i
WHERE i.state_type = 'started'
GROUP BY i.state
ORDER BY open_issues DESC;

Projects past their target date with open issues remaining.

SELECT
  p.name,
  p.target_date,
  COUNT(*) FILTER (WHERE i.state_type <> 'completed') AS open_issues,
  COUNT(*)                                            AS total_issues
FROM projects p
JOIN issues i ON i.project_id = p.id
WHERE p.target_date < CURRENT_DATE
  AND p.state <> 'completed'
GROUP BY p.name, p.target_date
HAVING COUNT(*) FILTER (WHERE i.state_type <> 'completed') > 0
ORDER BY p.target_date;

Quality trend; assumes a 'Bug' label via an issue_labels bridge table.

WITH bug_issues AS (
  SELECT i.*
  FROM issues i
  JOIN issue_labels il ON il.issue_id = i.id
  WHERE il.label = 'Bug'
)
SELECT
  weeks.week,
  COUNT(created.id)  AS bugs_created,
  COUNT(resolved.id) AS bugs_resolved
FROM (
  SELECT generate_series(
    date_trunc('week', CURRENT_DATE - INTERVAL '12 weeks'),
    date_trunc('week', CURRENT_DATE),
    INTERVAL '1 week'
  ) AS week
) weeks
LEFT JOIN bug_issues created
  ON date_trunc('week', created.created_at) = weeks.week
LEFT JOIN bug_issues resolved
  ON date_trunc('week', resolved.completed_at) = weeks.week
GROUP BY weeks.week
ORDER BY weeks.week;