GitLab CI monitoring
GitLab CI monitoring: every project, one view
Pipeline runs, DORA metrics, and flaky tests across every project in your group hierarchy. Works the same on gitlab.com and self-managed GitLab. Two-minute setup, one access token, no agents.
Projects · sorted by last pipeline · last 30 days
Works across every major CI/CD provider
Pipelines · DORA · Flaky tests
Beyond the Pipelines view
Three capabilities every CI/CD Watch tenant uses, each wired into how GitLab CI reports data. Same JSON sources GitLab uses, lifted into views the per-project Pipelines page does not offer. Identical behaviour on SaaS and self-managed.
Pipelines, every project, one feed
The Pipelines view works for one project. Twenty projects break it.
Every pipeline run across every project in your group hierarchy, in one live feed. Filter by status, project, branch, trigger source, or time. Drill straight back into the GitLab pipeline page when you need the raw logs.
- Live via efficient API polling, conditional-request aware against GitLab's 2,000/min project API ceiling on .com
- Trigger source visible on every row: push, merge_request_event, schedule, parent_pipeline
- Each row links straight to gitlab.com/<group>/<project>/-/pipelines/<id>
Outcome: one tab replaces fifty, on whichever GitLab you run.
What's needed: access token. Nothing in your .gitlab-ci.yml changes.
Pipelines across 18 projects · live
DORA, calculated from GitLab CI runs
Five DORA metrics, from your real pipeline run history.
DORA metrics calculated from real pipeline run data, including 2024's Rework Rate. Deployments auto-detect on main and master. Jobs declared with an environment: keyword are treated as deployments to that environment, with parent-child pipelines deduplicated.
- environment: jobs surface as deployments, scoped to the named environment
- Parent and child pipelines counted once per logical deploy, not double-counted
- Trend over 7 / 30 / 90 days, per-project or aggregated, with period-over-period regression alerts
Outcome: DORA defensible to leadership, without manual reporting.
What's needed: access token. Auto-detection covers projects using environment: already.
DORA by project · 30 days · ranked by deploy frequency
Flaky tests, surfaced via native JUnit reports
GitLab CI already reports JUnit. We surface every flake across the estate.
GitLab CI has a native test-report keyword (artifacts:reports:junit:). If you already declare it, there's nothing else to configure. Each test gets a flip rate, failure rate, and current status so the most disruptive ones surface first.
Native GitLab keyword, no upload step
test:
script: npm test
artifacts:
reports:
junit: junit.xml- Per-test flip rate scored across MR and main branches over a rolling 30-day window
- Failure rate and current status per test, sortable in the table
- Parallelised jobs (parallel: N) merged per logical test, not duplicated
Outcome: fix the disruptive tests first, with real flip-rate data to triage them.
What's needed: the artifacts:reports:junit:keyword. GitLab CI's native test reporting, nothing custom.
Flaky tests, last 30 days, sorted by flip rate
Same connect, more depth
How we work with GitLab CI
Three more capabilities the same connect unlocks. None of them are GitLab-only, but each pays off particularly well on GitLab estates where Auto DevOps, parent-child pipelines, and self-managed runners all swing the numbers.
Cost
Cost-optimization opportunities ranked by potential saving
Right-sizing recommendations, redundant-step detection, and waste categorisation. Each opportunity shows what to change and the annualised saving for taking the action.
Audit
Audit rules catch CI/CD hygiene gaps across the estate
Built-in rules check for missing lint, no unit tests, absent SAST, secrets-in-config patterns, and more. Findings ranked by severity; each one names the project and the fix.
Strategy
Branching strategy auto-detected per project
Trunk-based, GitFlow, GitLab-flow detected from your real branch and merge patterns. DORA metrics get a per-strategy lens so trunk-based projects aren't penalised for not having long-lived release branches.
All from one connect
Plus the rest of the toolkit
The three capabilities above are what you'll use most. Same connect also gives you cost tracking, MR health, stability classification, performance ratings, security insights, Slack, CLI, and an MCP server. No extra integrations.
Cost tracking →
Compute charges plus developer wait time. Waste auto-categorised by type. Team tier.
MR health →
Per-project CI failure rates, reviewer wait time, and MR-to-deploy latency. Team tier.
Stability classification →
Every pipeline auto-classified healthy, flaky, or broken. Trend detection on each.
Performance ratings →
Per-pipeline performance scoring across the estate. Spot the slow outliers.
Security insights →
Per-project security-scan detection rolled up across the estate. Business tier.
Slack notifications →
Pipeline failures, regressions, and degradation alerts in your team channel. Team tier.
CLI →
Query pipeline status, costs, and DORA from your terminal. Pipe it anywhere.
MCP server →
Hook Claude, Cursor, or any AI agent into live pipeline state.
Pricing
Flat per tenant
Start free for one team. Team and Business tiers are flat monthly rates per tenant. Enterprise is custom for organisations needing SSO, audit logging, and security review.
Free
For one team getting started with up to 3 projects.
- 3 projects
- 1 team member
- Pipeline runs, DORA, flaky tests
- Cost view (last 30 days)
- Email support
Team
Flat rate per tenant. Up to 20 projects and 10 team members.
- 20 projects
- 10 team members
- Everything in Free
- Cost tracking with full history
- MR health, performance ratings
- Slack notifications, CLI, MCP server
Business
Flat rate per tenant. Up to 100 projects and 50 team members.
- 100 projects
- 50 team members
- Everything in Team
- Audit findings and cost-optimization opportunities
- Priority support
Comparison
How CI/CD Watch compares
A 10-person team running GitLab CI across ~20 projects. Headline pricing only; deeper feature comparisons live on the linked pages.
CI/CD Watch$29 / mo flat (Team) | ||||
|---|---|---|---|---|
| Pipeline run monitoring | Live cross-project feed | Yes | Limited | Yes |
| DORA metrics from CI data | All five, auto-detected | Add-on | Yes | No |
| Self-managed GitLab support | Yes, same product | Yes, with config | Partial | Yes |
| Cost tracking (compute + wait time) | Yes, with wait time | Compute only | Wait time only | No |
| Pricing model | Flat per tenant | Per committer + spans | Per contributor | Flat tiers |
| Setup time | ~2 min access token | Agent install per repo | OAuth + config | ~5 min |
Competitor pricing reflects each vendor's published headline rate. See the linked comparison pages for fuller feature matrices and verified sources.
~2 min
to connect via access token
0
agents to install in your runners
5
DORA metrics from day one
Flat
per-tenant pricing
FAQ
GitLab CI specifics
- How is this different from GitLab's built-in analytics?
- GitLab's analytics live per-project (Analytics > CI/CD) or are surfaced piecemeal across the Premium and Ultimate plans. CI/CD Watch is the cross-project view: one feed across every project, DORA aggregated across them, flaky tests sortable across the estate. Works the same on Free, Premium, Ultimate, and self-managed.
- Will it slow down our pipelines or eat into our minutes?
- No. CI/CD Watch reads from GitLab's API after pipelines complete. It does not modify your .gitlab-ci.yml, install runners, or trigger billable jobs. The polling is rate-limit-aware and stays comfortably under the 2,000/min project API ceiling using conditional requests.
- How does CI/CD Watch get our pipeline data?
- Via the standard GitLab REST API using a personal or group access token you generate at connect time (read-only on pipelines, jobs, and project metadata). No webhooks, no GitLab app install needed, no runners modified.
- What if we use parent-child pipelines for deploys?
- The deployment-classification model accounts for parent-child pipelines, deduplicating so a single logical deploy isn't counted twice. Deploys are auto-detected from the environment: keyword on the deploying job, regardless of which child pipeline runs it.
- Does it work on self-managed GitLab?
- Yes, same product, same view. Outbound HTTPS from us to your GitLab instance using the access token. No inbound network changes required. Works on every self-managed version we test against (Free, Premium, Ultimate).
- How long does setup take?
- Around two minutes. Generate a read-only access token in GitLab, paste it into CI/CD Watch, pick which projects to include. The first pipeline feed populates within minutes.
- Is pricing tied to pipeline minutes or seats?
- Neither. CI/CD Watch is flat per tenant: $0 Free, $29 Team, $99 Business per month. Project and team-member caps differ per tier; consumption inside those caps is unmetered.
- Can we get DORA metrics across GitLab CI and GitHub Actions or Jenkins?
- Yes. Connect each provider separately; DORA metrics include runs from every connection. Useful for mixed estates mid-migration where part of the team has moved to GitLab and part is still on legacy CI.
- What scopes does the access token need?
- Read-only on api, read_repository, read_user, and read_api for group-level tokens. We never request write scopes. The exact list is shown on the connect screen so you can verify before generating the token.
More on CI/CD monitoring
Read, compare, or get started
Blog
What are DORA metrics and why should you track them?
The four (now five) signals from DORA Research that measure how well a software team delivers. What each one means and how to read them.
Guide
Deployment detection
Auto-detection from environment: keywords. Configure named rules for parent-child pipelines or non-default branches.
Guide
Audit
How CI/CD Watch audits your pipelines for missing tests, missing lint, and other CI/CD hygiene gaps.
Blog
Flaky tests: what they are, why they happen, how to fix them
Practical patterns for catching flaky tests early, ranking them by impact, and clearing them without halting feature work.
Blog
The true cost of CI/CD: compute, wait time, and waste
Compute is half the bill. Developer wait time is usually the bigger half. The taxonomy of CI/CD cost and where the waste lives.
Blog
CI/CD monitoring: beyond watching pipelines go green
What estate-level CI/CD monitoring should actually surface, and where most dashboards stop short.
One tab replaces fifty.
Connect GitLab CI in two minutes. Pipeline runs, DORA, and flaky tests across every project, on SaaS or self-managed.