How to build Linear analytics dashboards in Metabase

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

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

codex mcp add linear --url https://mcp.linear.app/mcp
codex mcp add metabase --url https://your-metabase.example.com/api/metabase-mcp

[features]
experimental_use_rmcp_client = true

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

[mcp_servers.metabase]
url = "https://your-metabase.example.com/api/metabase-mcp"

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

Create a polished Metabase dashboard for Linear analytics using the available
Linear tables in this database.

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

First, inspect the schema and identify the available Linear tables. 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.

Important:
- Treat MCP data access as exploratory only.
- Build the dashboard from durable database/warehouse tables.
- If status history is missing, do not calculate true cycle time, scope change,
  time in status, or reopen rate. Use a caveat instead.
- Do not claim Metabase connects natively to Linear unless that is explicitly
  true in this environment.

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.

Before finalizing, create or recommend reusable Metabase 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 schema. 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;