Customer Reference Program

On this page

Customer Reference Program

The goal of our Customer Reference Program is to provide opportunities for customers to share their story on how GitLab has helped them overcome the challenges, blockers and pain points within their organizations.

The goals of the Gitlab Customer Reference Program include:

Customer Reference Types

Some examples of the types of assets we'd use as customer references once we have approval from the customer:

Customer Case Studies

The most recent customer case studies are found on the GitLab customer's page. When we build case studies, we need to have quantifiable metrics and business value to help describe how GitLab helped a customer achieve a signficant business result. Below are a sample of KPIs / dimensions we need to find in a good case study.



Business Value

Better / Quality

If a proposed customer case study doesn't have at least one metric to include, then we consider working with the account team to help identify a solid metric before building the case study.

Customer references collection

Today, we don't have a central collection for customer service, but we are starting to build one. For now we are capturing customer stories in an issue. If you have a customer story or anecdote leave a comment on issue 1834.

To initiate a formal case study process, follow the process listed here

Reference Program Process

  1. Adding a new reference customer
    1. AE nominates customer for the program to Customer Reference Manager
    2. CRM - AE briefing
      Key info needed:
      • Industry / Vertical
      • Region/Geo - Tier (core, starter, premium, ultimate) - [GitLab Use Case] ( - Customer Segment (strategic, large, smb) - Deployment size (licenses) - Customer Story (why GitLab, key metrics, etc) - Who did we beat?
        3. AE Introduces CRM to customer
      • Describe the Customer Reference program - Describe the types of reference activities and gauge their interest
      • Gauge their interest participation level

Sample Interview Questions/topics

* What led you to GitLab, what problems were you trying to solve?
* Why did you choose GitLab and what other tools were you using or considering?
* What has been your experience with GitLab?  
* How did you make the business case for GitLab and what metrics have you seen improve?
* What have you heard from the GitLab users, what was the adoption curve like? <br>
4. Update Customer Reference Spreadsheet (future SFDC) with details from interview to make sure the customer is identified as a potential reference and their desired activity level.

GitLab DevOps Customer Advisory Board

Purpose: To help foster DevOps transformation and adoption we are establishing a Customer Advisory Board, where we focus on sharing DevOps best practices and lessons learned with each other. We believe that transparency and sharing is a key way to help encourage the success of DevOps transformations. The GitLab customer advisory board is intended to be home to learning and collaboration so we can all experience success through DevOps transformation.

Members Executives/Champions for DevOps within their organizations

Frequency: We will try to meet virtually every 6 to 8 weeks

Membership: Approximately 15 - 20 customers, GitLab

Open by default: In alignment with GitLab values, our CAB discussions and sharing will be open and transparent. We intend to livestream the meetings. (Anonymized in the meeting)

GitLab Special Interest Group

Purpose: We are forming Special Interest Groups to foster specific and focused discussions about how to apply DevOps practices and GitLab capabilities in specific domains such as planning, development, CI/CD, security, etc. These Special Interest Groups will encourage sharing and collaboration of DevOps best practices and lessons learned between users and GitLab.

We believe that transparency and sharing is a key way to help us all learn and improve how we deliver for our customers. GitLab special interest groups are intended to be home to learning and collaboration.

Members Technical utilizers and advocates of GitLab

Frequency: We will try to meet virtually every 6 to 8 weeks

Membership: Approximately 8-15 users, GitLab Product Manager

Open by default: In alignment with GitLab values, our SIG discussions and sharing will be open and transparent. We intend to livestream the meetings. (Anonymized in the meeting)

Customer Anecdotes

Customer anecdotes are short, "snackable" customer stories. These can be used on a call or in a meeting to share a point about GitLab by validating it with the customer story. An anecdote can be a summary of a formal, attributable case study or just an annonymouse story from a conversation you had with a customer. It's important to keep customers annonymous unless we have explicit approval to use their name.

Administrative overhead

We hosted a dinner for customers and prospects to mingle with each other and share stories. When the topic of managing the DevOps toolchain came up, the Head of Risk at a large US bank mentioned that she had a team of 20 to keep SDLC tools running in her org. A GitLab customer, the managing director of a product group for a global investment management corporation said, "this is going to break your heart, but I have 1 guy that spends 25% time to keep GitLab up and going for my team of 1500 devs."

Deliver value faster

Pinterest is not a GitLab customer, but uses Kubernetes together with Jenkins. Because there's no native kubernetes integration for Jenkins they needed to dedicate a team of 4 spending 6 months to build a custom system to control access managment and allow teams to to self-serve builds. This is functinoality that comes out of the box on day one with GitLab.


A large enterprise in the software space is a recent GitLab Premium customer wanting to replace Perforce. They predicted that it would take them 3 years to hit 6K active users. But, the developer experience was so superior that they ended up hitting 6K active users in only 8 months.

Ticketmaster - 15x Faster Build time

Ticketmaster is the global event ticketing leader with one of the world's top five ecommerce sites, getting almost 27 million monthly unique visitors. Ticketmaster was using Jenkins for continuous integration. Weighed down by plug-ins and legacy development, their pipeline was taking 2 hours to complete. After getting stuck late on a Friday night waiting for the build to complete their ops team got fed up and began to explore other options. They were able to run their pipeline on GitLab CI/CD in 8 minutes for a 15x increase.

Axway - 26x faster release cycles

Axway, is a global enterprise software company with over €300 million in yearly revenue. Axway wanted to adopt DevOps practices but their legacy Subversion toolchain was blocking them. By moving from Subversion to Git using GitLab as their Source Code Management (SCM) solution they were able to implement DevOps integrating GitLab into tools like JIRA, for issue management and Jenkins for continuous integration. They increased demployents from once-a-year to every two weeks.

Paessler - 120X Increased QA efficiency

Paessler AG provides the award-winning PRTG Network Monitoring software used by over 150,000 IT administrators in more than 170 countries. QA engineers were manually testing software with a routine set of tasking taking an hour to complete. By implementing GitLab pipelines they were able to automate QA tasks requiring only 3 minutes of effort for a 120x efficiency increase.

Equinix - increased DevOPs agility

Equinix is a leading global data center company . Their client-side development teams responsible for building software products and business critical applications increase development speed, self-serviceability and ability to ship fixes and features quickly. Equinix needed a version control and continuous integration tool for distributed workflows to support globally distributed development teams.