GitLab Monitoring and Analytics
GitLab collects data on every commit, pipeline, merge request, and deployment. Its built-in analytics and monitoring tools surface that data as actionable reports so teams can measure performance, find bottlenecks, and improve over time.
Where to Find Analytics in GitLab
Project sidebar:
├── Analyze
│ ├── Value stream analytics ← time from idea to production
│ ├── CI/CD analytics ← pipeline success rates and duration
│ ├── Repository analytics ← code frequency and contributors
│ ├── Merge request analytics ← MR throughput and review time
│ └── Issue analytics ← issue velocity and resolution time
Group sidebar:
└── Analyze
├── Productivity analytics ← team-level MR and issue metrics
├── DevOps adoption ← which features the group uses
└── Value stream (group) ← cross-project pipeline
Value Stream Analytics — The End-to-End Picture
Value stream analytics measures how long work takes to travel through each stage of your development process. A stage is the time between two events.
Idea → Issue → Plan → Code → Test → Review → Staging → Production
│ │ │ │ │ │ │ │
└──────────────────────────────────────────────────────────┘
Total lead time (goal: as short as possible)
Example breakdown:
────────────────────────────────────────────────────
Issue created → MR opened: 3.2 days (Plan)
MR opened → MR merged: 1.1 days (Review)
MR merged → Pipeline done: 0.4 hours (Test)
Pipeline done → Live on prod: 0.2 hours (Deploy)
────────────────────────────────────────────────────
Total lead time: 4.8 days
A long "Review" stage means MRs sit waiting for approval. A long "Plan" stage means issues sit without someone picking them up. The data points to the exact bottleneck.
CI/CD Analytics
Go to Analyze → CI/CD Analytics to see pipeline performance over time.
CI/CD Analytics — last 30 days ──────────────────────────────────────────────────────────── Total pipelines: 312 Success rate: 91.3% Failed: 27 (8.7%) Avg duration: 7m 42s Longest duration: 23m 11s ──────────────────────────────────────────────────────────── Duration trend (weekly average): Week 1: ████████ 8m 12s Week 2: ███████ 7m 44s Week 3: ██████ 7m 01s ← improving ✅ Week 4: ██████ 7m 42s
A rising average duration signals that your test suite or build steps are growing slower. A dropping success rate signals flaky tests or dependency issues that need attention.
Repository Analytics
Repository analytics shows code contribution patterns over time. Access it at Analyze → Repository Analytics.
Commits per month (last 6 months): ─────────────────────────────────────────────────────────── Jan: ████████████ 120 Feb: ██████████ 98 Mar: ████████████████ 162 ← sprint push Apr: █████████ 90 May: ███████████ 110 Jun: █████████████ 131 ─────────────────────────────────────────────────────────── Top contributors: Sara → 312 commits Arjun → 280 commits Riya → 198 commits
Programming Languages Used
GitLab detects every language in the repository by file extension and shows a breakdown by percentage. This is useful for onboarding new team members and for tracking technology migration.
Repository language breakdown: JavaScript ████████████████░ 58% Python ███████░ 25% CSS ████░ 14% Shell █░ 3%
Merge Request Analytics
MR analytics tracks how long reviews take and how many MRs your team ships per week. Access it at Analyze → Merge Request Analytics.
MR Analytics — last 30 days ──────────────────────────────────────────────────── MRs opened: 41 MRs merged: 38 MRs closed: 3 Avg time to merge: 18.4 hours Avg review comments: 4.2 per MR ────────────────────────────────────────────────────
An average time-to-merge above 48 hours is a common indicator that the review process needs attention — perhaps more reviewers, clearer review guidelines, or smaller MRs.
Issue Analytics
Issue analytics shows how many issues open and close each month. A growing gap between opened and closed issues means the team is accumulating backlog faster than they resolve it.
Issue Analytics — Monthly View ──────────────────────────────────────────────────────── Month Opened Closed Net Change ──────────────────────────────────────────────────────── April 22 18 +4 (backlog growing) May 19 21 -2 (backlog shrinking) ✅ June 25 20 +5 (backlog growing again) ────────────────────────────────────────────────────────
DORA Metrics — Industry-Standard DevOps Benchmarks
GitLab measures four DORA (DevOps Research and Assessment) metrics that the industry uses to benchmark software delivery performance:
| Metric | What It Measures | Elite Performance |
|---|---|---|
| Deployment frequency | How often you ship to production | Multiple times per day |
| Lead time for changes | Commit to production time | Less than 1 hour |
| Change failure rate | Percentage of deployments causing incidents | 0–5% |
| Time to restore service | How fast you fix a production failure | Less than 1 hour |
View DORA metrics at Analyze → Value stream analytics → DORA metrics.
Error Tracking
GitLab Error Tracking integrates with Sentry to display application errors directly inside GitLab. Go to Monitor → Error Tracking to see a list of exceptions your production app has thrown, with stack traces, frequency, and affected users.
Error Tracking
──────────────────────────────────────────────────────────────────
Error Count Users First seen
──────────────────────────────────────────────────────────────────
TypeError: Cannot read property 142 38 2 days ago
'id' of undefined — payment.js:81
ConnectionError: DB timeout 23 9 5 hours ago
404 Not Found — /api/users/profile 8 8 1 day ago
──────────────────────────────────────────────────────────────────
Incident Management
When production breaks, GitLab Incident Management creates a structured incident record. Go to Monitor → Incidents → Create incident. An incident tracks the timeline, assigns responders, links related issues and MRs, and records the resolution steps.
Incident #7 — Payment service down ──────────────────────────────────────────────────────────────── Severity: Critical Opened: 14:32 UTC by PagerDuty alert (auto-created) Assignee: Arjun Status: Mitigated Timeline: 14:32 Alert fired — payment API error rate 45% 14:38 Arjun acknowledges incident 14:51 Root cause found: DB connection pool exhausted 15:04 Fix deployed — error rate back to 0.1% 15:10 Incident closed. Total duration: 38 minutes ────────────────────────────────────────────────────────────────
Using Analytics to Drive Improvement
Data without action is just noise. Use these analytics in a regular team review (weekly or per-sprint):
- Check CI/CD success rate — investigate any jobs with failure rates above 10%
- Review average MR merge time — reduce it by breaking large MRs into smaller ones
- Track lead time for changes — identify which pipeline stage consumes the most time
- Monitor open vs closed issue trend — reprioritise if backlog grows two months in a row
- Compare DORA metrics month-over-month — celebrate improvements, investigate regressions
GitLab analytics turns invisible team habits into visible, measurable numbers. Teams that review these metrics regularly ship faster and maintain higher quality over time.