How do you build GitHub analytics dashboards in Metabase?

GitHub holds your pull requests, reviews, commits, Actions runs, and deploys. Metabase turns that into shared engineering dashboards. Metabase reads SQL databases — there's no native GitHub connector — so durable DORA and velocity dashboards start with a sync. For the engineering picture across tools, see the software delivery analytics overview; for a self-managed alternative, see GitLab.

How do you connect GitHub 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.

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

Pair the GitHub MCP server with the Metabase MCP server for live, conversational analysis. The GitHub MCP pulls current PR, review, and Actions data; the Metabase MCP queries the models and dashboards you've already built.

Example workflows

• List PRs awaiting review on the default branch, then summarize by team.
• Pull a repo's failing workflow runs from GitHub and cross-check against a Metabase CI model with the Metabase MCP.
• Draft a SQL question in Metabase from a natural-language ask, using GitHub MCP output to confirm field meanings.
• Triage: "show open PRs older than 7 days with no review" straight from GitHub — 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 DORA analysis still needs synced data in a database.
• Respect GitHub API rate limits and repo access scopes.
• OAuth on the hosted server requires a GitHub Copilot license; a Personal Access Token works without one.
• The Metabase MCP server is built in; an admin enables it under Admin → AI → MCP.

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

# GitHub (remote, OAuth in browser — OAuth requires a Copilot license)
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

# Or authenticate with a Personal Access Token instead of OAuth
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer ghp_your_token"

# 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.

codex mcp add github --url https://api.githubcopilot.com/mcp/
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:

[features]
experimental_use_rmcp_client = true

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"

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

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://api.githubcopilot.com/mcp/"]
    },
    "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 GitHub data in Metabase?

• PR throughput — PRs opened vs. merged per week, by repo and team
• PR cycle time & lead time — created → first review → merge → deploy
• Code-review health — time to first review, review latency, PRs merged without review, reviewer load
• CI/CD reliability — Actions workflow pass rate, run duration, repeatedly failing jobs
• Deployment frequency (DORA) — production deploys per day/week
• Change failure rate & MTTR (DORA) — failed deploys and time to restore
• Contributor activity — commits, active contributors, review participation
• Stale & WIP — aging open PRs, oldest drafts

Which GitHub dashboards should you build in Metabase?

• Engineering velocity — PR throughput and cycle time → see software delivery.
• Code-review health — time-to-first-review, review latency, unreviewed merges, reviewer load.
• CI/CD reliability — Actions pass rate and median run duration, worst-offending workflows.
• DORA metrics — deployment frequency, lead time for changes, change failure rate, MTTR.

How should you model GitHub data in Metabase?

Map GitHub's objects to a clean model (don't report off raw connector tables):

• Flag bot accounts (is_bot, or match dependabot/renovate) and exclude them from contributor metrics.
• Restrict merge/flow analysis to each repo's default_branch — don't count every branch.
• Derive cycle time from created_at → merged_at and review latency from the first pr_reviews.submitted_at.
• Join deployments to commits/PRs by sha to compute lead time for changes.

Can you generate a GitHub 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 "GitHub Engineering Health & DORA" from the
synced GitHub tables in this database. Inspect the schema first; do not assume
table names. Map raw tables to: pull_requests, pr_reviews, commits,
repositories, workflow_runs, deployments, users. Filter out bot accounts
(e.g. dependabot, renovate) and restrict merge analysis to the default branch.

Sections: (1) Velocity — PRs opened vs merged per week, by repo and team;
(2) Flow — median PR cycle time (created to merged) by week, p90, open-PR age;
(3) Review health — median time to first review, share of PRs merged without
review, reviewer load; (4) DORA — deployment frequency, lead time for changes,
change failure rate, and MTTR; (5) CI — Actions workflow pass rate and median
run duration.

Only compute change failure rate and MTTR if deployment outcomes or linked
incidents exist; otherwise add a caveat. Build durable questions from database
tables, treat MCP as exploratory, and do not claim a native GitHub connector.
Add filters for repository, team, author, branch, and date range.

What SQL powers GitHub dashboards in Metabase?

SELECT
  date_trunc('week', pr.merged_at) AS week,
  COUNT(*)                                                              AS merged_prs,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (pr.merged_at - pr.created_at)) / 3600
  )                                                                     AS median_cycle_hours
FROM pull_requests pr
WHERE pr.merged_at IS NOT NULL
  AND pr.base_ref = 'main'
GROUP BY 1
ORDER BY 1;

SELECT
  date_trunc('week', d.created_at) AS week,
  COUNT(*)                         AS deployments,
  COUNT(DISTINCT d.repository_id)  AS repos_deployed
FROM deployments d
WHERE d.environment = 'production'
GROUP BY 1
ORDER BY 1;

SELECT
  date_trunc('week', wr.created_at) AS week,
  COUNT(*)                                                  AS runs,
  AVG((wr.conclusion = 'success')::int)                     AS pass_rate
FROM workflow_runs wr
WHERE wr.head_branch = 'main'
GROUP BY 1
ORDER BY 1;

What are common mistakes when analyzing GitHub in Metabase?

Related

Integrations

Dashboards

Metrics

FAQ