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

How do you connect GitLab to Metabase?

Most teams combine both routes: use the GitLab 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 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 do you use the GitLab MCP server with the Metabase CLI?

Pair the GitLab MCP server with the Metabase CLI for fast, hands-on analysis. GitLab ships a first-party MCP server (Duo) that looks up live merge requests, approvals, and pipelines; 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.

Example workflow

• Ask the GitLab MCP which MRs are waiting on approval, or list a project's failed pipelines this week.
• Export the merge requests, approvals, 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 GitLab 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 so analysis can't trigger writes.
• mb upload csv needs an uploads database configured under Admin → Settings → Uploads.

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

# GitLab (remote, OAuth in browser) — swap the host for self-managed
claude mcp add --transport http gitlab https://gitlab.com/api/v4/mcp

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

codex mcp add gitlab --url https://gitlab.com/api/v4/mcp

First remote MCP in Codex? Enable the rmcp client in ~/.codex/config.toml:

[features]
experimental_use_rmcp_client = true

[mcp_servers.gitlab]
url = "https://gitlab.com/api/v4/mcp"

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

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. On first connection the GitLab 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 GitLab CSV export — creates a table AND a model
mb upload csv --file gitlab-merge-requests.csv --collection root

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

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

Can you generate a GitLab dashboard with AI?

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

Create a Metabase dashboard called "GitLab 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 MR velocity, flow, review health,
DORA metrics, and pipeline reliability from GitLab data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for GitLab tables and
  models). If durable GitLab 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 GitLab MCP server using a read-only
  token: merge requests, approvals, pipelines, deployments, projects, commits,
  and users. 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: merge_requests, mr_approvals, pipelines, deployments,
projects, commits, users. Filter out bot/service accounts and restrict merge
analysis to each project's default branch. Inspect the actual tables and column
names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  GitLab — it reads a database or CLI-uploaded tables.
- A merged MR 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 — 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.

Filters: project, group, 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 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.

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.

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