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. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync GitHub into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector. 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?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native GitHub connector. So connecting GitHub to Metabase means one thing: run a small pipeline that copies GitHub data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.

The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.

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.

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.

Can you generate a GitHub dashboard with AI?

Yes — and once GitHub data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.

Two ways to let an assistant query and build in Metabase

Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:

Set up the Metabase MCP server

Enable it under Admin → AI → MCP, then point your client at the endpoint:

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

{
  "mcpServers": {
    "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. Confirm the current endpoint in the Metabase MCP docs.

Set up the Metabase CLI

Install it globally, then authenticate once (the binary is mb):

# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli

# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth status

On Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.

Prompt: build the GitHub Engineering Health & DORA dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

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