Connect GitLab

What it pulls

Groups, projects, merge requests (open + merged + cycle time), pipelines & failures, deployments, releases, vulnerability findings (where licensed), stale projects.

The exact fields the connect form asks for — and where to find each value.

GitLab hostoptional

Leave blank for gitlab.com. Self-managed only: your instance root like https://gitlab.example.com — NOT a project or /username URL.

Access token (read_api)

GitLab → your avatar → Edit profile → Access Tokens → check read_api + read_repository → Create → copy the glpat-… value (shown once).

1. 1

   Open Access Tokens

   Use the link above, or GitLab → your avatar → Edit profile → Access Tokens (personal), or a group’s Settings → Access Tokens.

2. 2

   Select read-only scopes

   Name it “ShipReady Metrics”, set an expiration, and check both read_api and read_repository — those are the only scopes we need.

3. 3

   Create and copy the token

   Click Create token and copy the glpat-… value — it is shown only once.

4. 4

   Set the host correctly (this is the #1 mistake)

   For gitlab.com, LEAVE the GitLab host field blank. For self-managed, use the instance ROOT (e.g. https://gitlab.example.com). Do NOT enter a project or user/namespace URL like https://gitlab.com/yourname — that redirects to the sign-in page and the connection fails.

5. 5

   Paste the token and connect

   Enter the token in Access token (read_api) and click Connect. We validate it live, encrypt it at rest, and run the first sync.

Troubleshooting

“did not return JSON” / it redirects to a sign-in page.

The host is wrong. Leave it blank for gitlab.com; for self-managed use the instance ROOT (https://gitlab.example.com) — never a project, group, or /username URL.

Security Readiness shows no vulnerabilities.

Vulnerability findings require GitLab Ultimate. On Free/Community the connector omits vuln counts rather than faking a clean 0 — Delivery Health and Technical Debt still populate.