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. This guide covers two complementary paths: a lightweight MCP + CLI route that pulls live data with the GitHub MCP server and loads a CSV into Metabase with the Metabase CLI for quick analysis, and a durable pipeline route that syncs GitHub into a database so you can build DORA and velocity dashboards anyone can read.

How do you connect GitHub to Metabase?

Most teams combine both routes: use the GitHub MCP server and Metabase CLI route to pull live data and stand up a quick analysis, and the pipeline route for the DORA and velocity dashboards engineering leaders depend on.

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 do you use the GitHub MCP server with the Metabase CLI?

Pair the GitHub MCP server with the Metabase CLI for fast, hands-on analysis. GitHub hosts a first-party remote MCP server that looks up live PRs, reviews, and Actions runs; the Metabase CLI's upload command loads a CSV into Metabase and creates a ready-to-query table and model. For analysis, use a read-only token or the read-only MCP variant.

Example workflow

• Ask the GitHub MCP which PRs are stuck in review on the default branch, or list failing workflow runs for a repo.
• Export the pull requests, reviews, and deployments you want to keep as CSVs.
• Run mb upload csv to load them into Metabase as tables and models, then build questions and dashboards on top.

Be honest about the limits

• The GitHub MCP is great for live lookups — not for scheduled or audited DORA reporting.
• A CSV upload is a point-in-time snapshot; trend and DORA history still need a warehouse sync, or refresh with mb upload replace.
• Use a read-only token or the /mcp/readonly endpoint so analysis can't trigger writes.
• mb upload csv needs an uploads database configured under Admin → Settings → Uploads.

How do you set up the GitHub MCP server and the Metabase CLI?

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

Claude Desktop: add GitHub as a remote/custom connector (Settings → Connectors) using the same URL; Claude handles the OAuth pop-up.

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

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://api.githubcopilot.com/mcp/"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. On first connection the GitHub server opens a browser window to authorize.

# 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 GitHub CSV export — creates a table AND a model
mb upload csv --file github-pull-requests.csv --collection root

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

The Metabase CLI stores its credentials securely after mb auth login.

Can you generate a GitHub dashboard with AI?

Yes. Use the prompt below with any assistant that can run the GitHub MCP server and the Metabase CLI. It works end to end: if GitHub tables already exist in Metabase it analyzes those; otherwise it pulls the data over the GitHub MCP, loads it with mb upload csv, then builds the dashboard — skipping cards it has no data for.

Create a Metabase dashboard called "GitHub Engineering Health & DORA".
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help engineering leaders understand PR velocity, flow, review health,
DORA metrics, and CI reliability from GitHub data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for GitHub tables and
  models). If durable GitHub 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 GitHub MCP server using a read-only
  token: pull requests, reviews, commits, repositories, workflow runs, and
  deployments. 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 table names. Map the available raw tables into these analytical
concepts where possible: 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. Inspect the actual
tables and column names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  GitHub — it reads a database or CLI-uploaded tables.
- A merged PR is not a deployment: only compute change failure rate and MTTR if
  deployment outcomes or linked incidents exist; otherwise add a caveat.
- Only build a card if its underlying column/metric exists in the data.
- A single CSV is a point-in-time snapshot: cycle-time trends and DORA history
  need a warehouse sync or multiple uploads, so build trend cards only if that
  history is present.

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.

Filters: repository, team, author, branch, and date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
build durable models from the database tables.

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.

How do you build the GitHub → Metabase pipeline?

For dashboards that need history and reliability, land GitHub data in a database first, then connect Metabase to that database.

Connector options

• dlt (free, code) — wrap GitHub's REST or GraphQL API in a small Python pipeline for incremental, no-vendor loads. The lightest path to a maintainable sync.
• GitHub REST / GraphQL API (free, raw) — write your own script that paginates PRs, reviews, workflow runs, and deployments and upserts on a schedule.
• Airbyte — has a GitHub source connector; free if you self-host the open-source version, paid on Airbyte Cloud.
• Fivetran (paid, managed) — a maintained GitHub connector with incremental syncs and zero maintenance.

Notes

• Land raw tables first, then build clean models on top.
• Restrict merge/flow analysis to each repo's default branch, and flag bot accounts so they don't skew contributor metrics.
• Sync real deploys (Deployments/Actions data), not just merges, if you want accurate DORA numbers.

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.

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