New GitLab metrics and registry features help reduce CI/CD bottlenecks

Platform and DevOps engineers spend too much time piecing together visibility across fragmented tools and managing infrastructure that should just work.

Two new GitLab features currently in beta tackle this from different angles but share the same goal: giving practitioners direct control over the CI/CD infrastructure they depend on, without adding another third-party tool. One surfaces job-level performance data right where you monitor pipelines. The other simplifies how you pull container images from multiple registries with built-in caching.

Both features are open for feedback now. Your input will help shape what ships next.

CI/CD Job Performance Metrics

• Available tiers: GitLab Premium, GitLab Ultimate
• Status: Limited-availability beta on GitLab.com; available on GitLab Self-Managed and GitLab Dedicated when ClickHouse is configured

Today, there’s no simple way to see when a particular job’s duration starts increasing or which jobs are quietly dragging down your pipeline runtimes. Most teams either build custom dashboards or manually dig through logs to answer basic questions like:

• Which jobs are slowest?
• Where are failure rates climbing?
• Which stage is the real bottleneck?

CI/CD Job Performance Metrics changes that by adding a new job-focused panel to the CI/CD analytics page at the project level.

For each job in your pipelines, you can see:

• Typical (P50, median) and worst‑case (P95) job duration, so you can quickly view normal versus slowest runs
• Failure rate, so you can spot fragile or flaky jobs
• Job name and stage, covering the last 30 days by default

The table is sortable, searchable by job name, and paginated, so platform teams get a single view to answer questions that previously required separate tools or custom reporting.

Try it now

• Navigate to your project and select Analyze > CI/CD analytics.
• Look for the CI/CD job performance metrics panel and sort by duration or failure rate to find your slowest or least reliable jobs.

Documentation

• CI/CD analytics – CI/CD job performance metrics

What’s coming next

We’re working on stage-level grouping, so you can view aggregated metrics across your build, test, and deploy stages, and quickly understand where to focus optimization work.

Share your feedback:

• CI/CD job performance metrics epic

Container Virtual Registry

Tier: GitLab Premium, GitLab Ultimate Status: Beta, API-ready in 18.9

Most organizations pulling container images into CI/CD pipelines rely on multiple registries: Docker Hub, Harbor, Quay, and internal registries, to name a few. Managing authentication, availability, and caching across all of them is operational overhead that slows pipelines down and introduces fragility.

The Container Virtual Registry lets you create a single GitLab endpoint that pulls from multiple upstream container sources with built-in caching.

Instead of configuring credentials and availability for each registry individually in your pipeline configuration, you can:

• Point your pipelines at one GitLab virtual registry endpoint
• Configure multiple upstream registries (Docker Hub, Harbor, Quay, and others using long-lived token authentication)
• Let GitLab resolve image pulls automatically, with pull-through caching to reduce bandwidth costs and improve reliability

For teams evaluating GitLab as a container registry replacement, this closes a critical capability gap. For teams already managing multi-registry container workflows, it centralizes image management into GitLab and cuts down on repeated pulls.

What the beta supports today

• Upstream registries using long-lived token authentication: Docker Hub, Harbor, Quay, and other compatible registries
• Pull-through caching so commonly used images are served from GitLab after the first pull
• API-first configuration, with UI management in progress++

Cloud provider registries requiring IAM authentication (such as Amazon Elastic Container Registry, Google Artifact Registry, and Azure Container Registry) are being considered for future iterations.

Test it today

• The Container Virtual Registry is API-ready in 18.9.
• SaaS (GitLab.com): Request access through your CSM or by commenting on the feedback issue below to have the feature flag enabled for your group.
• Self-managed: Enable the feature flag and configure the virtual registry using the API.

Documentation

• Container Virtual Registry API
• Pull container images from the virtual registry

Watch this walkthrough of the Container Virtual Registry Beta:

Share your feedback:

• Container virtual registry feedback issue

Help us build what matters

Everyone in the GitLab community is a contributor. We built these betas based on community requests.

• CI/CD Job Performance Metrics came from teams who had no easy way to see when build times started trending in the wrong direction, or which jobs were hurting pipeline reliability.
• Container Virtual Registry came from enterprise customers managing multiple registries and looking to reduce tool sprawl and bandwidth costs while evaluating GitLab as a central registry.

Your feedback shapes what we create next. Try one or both of these betas, and share your experience in the linked feedback issues.

This is the first in a series of Core DevOps betas we plan to highlight. More are coming throughout the year, and we hope you’ll help us make them as useful as possible.