How do you build GitLab analytics dashboards in Metabase?

GitLab holds your merge requests, approvals, commits, CI/CD pipelines, and deployments. Metabase turns that into shared engineering dashboards. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync GitLab 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 the GitHub equivalent, see GitHub.

How do you connect GitLab to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native GitLab connector. So connecting GitLab to Metabase means one thing: run a small pipeline that copies GitLab 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 GitLab data in Metabase?

• MR throughput — merge requests opened vs. merged per week, by project and group
• MR cycle time & lead time — created → first approval → merge → deploy
• Review health — time to first approval, approval latency, MRs merged without review, approver load
• Pipeline reliability — CI pipeline success rate, 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 MRs, oldest drafts

Which GitLab dashboards should you build in Metabase?

• Engineering velocity — MR throughput and cycle time → see software delivery.
• Review health — time-to-first-approval, approval latency, unreviewed merges, approver load.
• Pipeline reliability — CI success rate and median pipeline duration, worst-offending jobs.
• DORA metrics — deployment frequency, lead time for changes, change failure rate, MTTR.

How should you model GitLab data in Metabase?

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

• Flag bot/service accounts (bot) and exclude them from contributor metrics.
• Restrict merge/flow analysis to each project's default_branch— don't count every branch.
• Derive cycle time from created_at → merged_at and approval latency from the first mr_approvals.approved_at.
• Join deployments to commits/MRs by sha to compute lead time for changes.

How do you build the GitLab → Metabase pipeline?

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

Connector options

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

Notes

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

Can you generate a GitLab dashboard with AI?

Yes — and once GitLab 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 GitLab Engineering Health & DORA dashboard

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

Create a Metabase dashboard called "GitLab Engineering Health & DORA" from the
synced GitLab tables in this database. Inspect the schema first; do not assume
table names. Map raw tables to: merge_requests, mr_approvals, pipelines,
deployments, projects, commits, users. Filter out bot/service accounts and
restrict merge analysis to each project's default branch.

Sections: (1) Velocity — MRs opened vs merged per week, by project and group;
(2) Flow — median MR cycle time (created to merged) by week, p90, open-MR age;
(3) Review health — median time to first approval, share of MRs merged without
review, approver load; (4) DORA — deployment frequency, lead time for changes,
change failure rate, and MTTR; (5) CI — pipeline success rate and median
pipeline 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 GitLab connector. Add filters for project,
group, author, branch, and date range.

What SQL powers GitLab dashboards in Metabase?

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

SELECT
  date_trunc('week', d.created_at) AS week,
  COUNT(*)                         AS deployments,
  COUNT(DISTINCT d.project_id)     AS projects_deployed
FROM deployments d
WHERE d.environment = 'production'
  AND d.status = 'success'
GROUP BY 1
ORDER BY 1;

SELECT
  date_trunc('week', p.created_at) AS week,
  COUNT(*)                                          AS pipelines,
  AVG((p.status = 'success')::int)                  AS success_rate
FROM pipelines p
WHERE p.ref = 'main'
GROUP BY 1
ORDER BY 1;

What are common mistakes when analyzing GitLab in Metabase?

Related

Integrations

Dashboards

Metrics

FAQ