GitLab + AI = Your PM/QA Dashboard: How We Turn Issue Streams into Portfolio Decisions

GitLab is a phenomenal source of truth. It is also a terrible reporting tool.

If you have ever opened the GitLab "Insights" tab and tried to derive a real decision from it — "is this vendor on track? are we shipping faster this month? is QA actually finding more bugs or just opening more tickets?" — you know what we mean. The data is there. The narrative is not.

For three years we have built and refined a stack of dashboards on top of GitLab that gives PM, QA and finance teams something they can act on: AI-narrated weekly reports, anomaly detection, and a portfolio view across multiple projects, with the cost discipline that comes from running it on tooling you already own.

This is the honest write-up of what we built, what it costs, and where it beats — and loses to — Jira + Atlassian Intelligence.

Why GitLab Issues Alone Don't Tell You the Story

A typical mid-size engineering org generates 500-2000 issue events per week in GitLab: opens, closes, label changes, time-tracking, merge request links, comments. These are raw events. They are not decisions.

The four questions a head of engineering actually asks every Monday are:

1. Are we on track? Velocity, throughput, blockers, vendor SLAs.
2. Where are the risks? Anomalies — sudden bug spikes, stalled stories, vendor missed deadlines.
3. What needs my decision? Escalations that the team has not resolved themselves.
4. What is the cost story? Where did the hours go this week, and was it worth it?

GitLab's built-in "Insights" answers exactly none of these questions. It shows you charts. The charts are facts. The narrative is missing.

This is the gap we close.

What We Built: Three Dashboards on Top of GitLab

We do not run a generic dashboard tool. We built three opinionated, narrow-purpose dashboards, each tuned for a specific reader:

Dashboard 1 — PM Velocity (for the project manager)

• Stories opened / closed / in-flight per project per week.
• Time tracking actual vs estimate, per assignee and per vendor.
• Critical path: which issues are blocking which milestones.
• AI-written weekly narrative: "Project X shipped 18 stories this week, down from 24 last week. The drop is concentrated in the auth refactor (3 stories stalled on the integration test environment, which has been down since Tuesday). Action: unblock the test env or accept the slip on the M3 milestone."

The narrative is the differentiator. A junior PM gets the same Monday-morning context that a senior PM would assemble from twenty minutes of clicking around. The dashboard provides the structured data; an LLM (Claude Sonnet 4.6 in our default config) turns it into prose.

Dashboard 2 — QA Health (for the QA lead)

• Bug arrival rate, by severity, by component, by reporter.
• Mean time to QA, mean time to merge, mean time to close.
• Flaky test detection — issues that get reopened more than twice.
• AI-written narrative on anomalies only: "Bug arrival in the checkout module tripled this week (from 4 to 14). Most reporters are external (production users), not internal QA. Likely production regression from the May 8 deploy. Recommend rollback or hotfix priority."

We deliberately surface anomalies, not the firehose. The QA lead does not need to read a 12-page weekly report; they need to know what changed.

Dashboard 3 — Vendor Performance (for the head of delivery)

If you run a PMaaS engagement with multiple vendors or contractors, this is the dashboard that pays for everything else. Per-vendor metrics:

• Hours billed vs hours estimated.
• On-time delivery rate.
• Defect escape rate (bugs found post-merge per story shipped).
• Change-control compliance — did they file proper change requests for in-flight scope changes?
• AI narrative: "Vendor A shipped 14 stories this week, 12 on time, defect escape rate 7%. Vendor B shipped 9 stories, 4 late, defect escape rate 22%. Vendor B has missed the QA gate on 3 consecutive sprints. Recommend escalation in next steering committee."

This is what the executive monthly summary pipeline aggregates from — but at weekly cadence and with vendor-level granularity.

The AI Layer: Where the Magic (Actually) Is

The AI layer does three jobs, and only three:

1. Weekly Narrative Generation

Every Sunday night, a scheduled job pulls the week's GitLab data, normalizes it into a structured prompt, and asks an LLM to write a 200-word narrative per dashboard. The prompt is locked:

You are writing a PM weekly narrative. Use only the data provided.
Never invent metrics. If a number is missing, say so.
Format: TL;DR (one sentence), Top movers (2-3 bullets), Risks (1-2 bullets),
Recommendation (one sentence with a verb).
Tone: senior PM to head of engineering. No marketing language.

The narrative ships Monday at 7 AM to a Slack channel and to the dashboard top. The PM reads it before the standup, has context for 80% of the questions, and uses the standup for the other 20%.

2. Anomaly Detection

We do not use ML for this. We use simple rolling statistics — a 4-week median plus 1.5x interquartile range as the upper bound. Anything above that gets flagged. The AI's job is not to detect the anomaly; it is to explain it. Given the flagged data and the related GitLab context (issue comments, merge requests, commits), the LLM drafts the explanation and the recommended action.

This split matters. Stats are deterministic and cheap; AI explanation is the part where the LLM actually adds value. Reversing this (asking the LLM to detect anomalies) is how you spend a fortune on tokens and still get false positives.

3. Action-Item Extraction

At the bottom of each weekly narrative, the LLM extracts up to five action items, each formatted as a draft GitLab issue body — title, description, suggested labels, suggested assignee. The PM can one-click create the issue from the dashboard. This is the highest-leverage feature in the stack: it converts "I read the report" into "I created three issues" in 30 seconds.

The Multi-Project (Portfolio) View

For organizations running 4+ projects (typical for a PMaaS engagement or a multi-product company), we add a portfolio layer:

• One GitLab group → one portfolio.
• Each project rolls up its velocity, QA, and vendor metrics.
• Cross-project anomalies surface — "Vendor C is shipping faster on Project X but defect rate spiked on Project Y; possible context-switching cost."
• Quarterly steering committee export: PDF, branded, with the four AI narratives stitched together and an executive summary on page 1.

The data flow is straightforward:

GitLab API (REST + GraphQL)
   ↓
Postgres (normalized, deduped, time-indexed)
   ↓
dbt-style aggregations (velocity, QA, vendor materialized views)
   ↓
Dashboard UI (Next.js, Recharts)
   ↓
LLM narrative job (cron, weekly)
   ↓
Slack post + email + PDF export

Total infra cost for a 4-project portfolio: ~$140/month (Postgres on a managed plan, one small VM for the cron job, LLM API costs at roughly $8/week for the four narratives). The single biggest line item is engineering — the dashboards themselves required about 6 weeks of senior engineering to build, refine, and harden. We re-deploy the stack for new clients in 3-5 days now that the template exists.

Cost Comparison: This vs Jira + Atlassian Intelligence

The honest comparison, for a 50-person engineering org on a 4-project portfolio:

Where Jira wins: out-of-box for teams that need generic dashboards and have no engineering capacity to maintain a custom stack. Atlassian's network effects (every junior PM knows Jira) reduce onboarding cost.

Where this stack wins: you already use GitLab, you want vendor-performance dashboards (Jira has no native equivalent), you want custom AI narratives in your tone of voice, and you do not want to pay $20K/year per 50 users for reporting.

Implementation Pattern (For Engineering Teams Who Want to Build This Themselves)

If you are inclined to build it in-house rather than buy ours, the path is:

Step 1 — Stream GitLab events into Postgres

// Pseudocode for the ingestion job
const since = await db.getLastSyncTimestamp('issues');
const issues = await gitlab.issues.all({
  group: 'your-portfolio',
  updated_after: since,
  per_page: 100
});
 
for (const issue of issues) {
  await db.upsertIssue(issue);
  await db.recordEvents(issue.id, issue.events);
}

Run it every 15 minutes. Be polite to the GitLab API (rate limits exist). Backfill 90 days on first run; incremental thereafter.

Step 2 — Define materialized views

CREATE MATERIALIZED VIEW velocity_weekly AS
SELECT
  project_id,
  date_trunc('week', closed_at) AS week,
  COUNT(*) FILTER (WHERE state = 'closed') AS closed_count,
  COUNT(*) FILTER (WHERE state = 'opened') AS opened_count,
  SUM(time_spent_minutes) AS time_spent_minutes
FROM issues
WHERE closed_at > now() - interval '12 weeks'
GROUP BY project_id, date_trunc('week', closed_at);

Refresh weekly via cron. For QA and vendor views, the same pattern with different filters.

Step 3 — Wrap an LLM call around the structured data

const data = await db.getWeeklyDigest({ projectId, week });
const prompt = buildNarrativePrompt(data); // locked template
const narrative = await llm.complete(prompt, {
  model: 'claude-sonnet-4-6',
  max_tokens: 400,
  temperature: 0.2
});
await slack.post(`#pm-${projectId}`, narrative);

The locked prompt is the entire reason this works. Don't let the LLM be creative; let it be a translator from structured data to natural language.

Step 4 — Ship the dashboard, not the data

Render with Next.js + Recharts. The dashboard's top section is the AI narrative, the bottom is the supporting charts (in case anyone disagrees with the narrative and wants to look). Cache aggressively — dashboards rebuild on a schedule, not on every page load.

Where This Approach Fails

We disqualify ourselves first. Do not build this if:

• You have fewer than 3 active projects. The portfolio layer is overkill; native GitLab + a weekly all-hands meeting is enough.
• You don't have a PM or PMaaS engagement. Dashboards without a reader are decoration. Hire the reader first.
• You don't trust LLM narratives for executive consumption. We can't argue with that — but in that case, build it without the AI layer (the structured dashboards still beat the GitLab Insights tab).
• Your team is already on Jira and happy. Migration cost is real. The math only flips if you are already on GitLab.

What We Build For Clients

Our PMaaS engagement bundles this dashboard stack:

• 3-5 day deployment on your GitLab portfolio.
• Custom-tuned AI narratives in your tone (we will mirror your existing PM communication style).
• Slack/email/PDF distribution to the readers you specify.
• Quarterly steering committee export, branded.
• Monthly tuning session to adjust the prompts as your business evolves.

The dashboard ships as part of our PMaaS engagement — typically alongside a vendor audit, a change-control board, and the executive monthly summary.

Frequently Asked Questions

Does this work with self-hosted GitLab? Yes. The API endpoints are identical between GitLab.com and self-hosted (CE/EE 14.x+). For self-hosted we usually deploy on the same network for lower latency on the ingestion job.

Can the AI narratives be in Arabic or French? Yes. We pass the target language as a prompt parameter and lock the LLM to MSA Arabic or French. The structured data layer is language-neutral.

What about time tracking accuracy? The dashboard only shows what is in GitLab. If your team does not log time, the velocity-vs-estimate chart will be empty. We help clients onboard a time-tracking discipline before the dashboard goes live.

Can we integrate with Jira too? We don't recommend it — but technically yes, by writing a Jira API ingestion job parallel to the GitLab one. The downstream materialized views and LLM prompts are tool-agnostic.

Is the source available? Not as open-source. The stack is part of our PMaaS engagement. The patterns in this article are yours to use.

Want the dashboard on your GitLab portfolio?

Book a PMaaS audit — we will show you what your data looks like through this lens before you commit to anything.

Or read the executive monthly summary playbook and the vendor performance reporting guide for the broader PMaaS context.