Monetization Section

Mission

Enable customers to evaluate, buy, and manage GitLab offerings through a scalable monetization platform spanning purchase flows, billing engines, and the infrastructure, integrations, and compliance capabilities required to support them.

The Monetization and Fulfillment sections were split from a single Fulfillment section in August 2026. Monetization owns CustomersDot and its operations. The Fulfillment section owns entitlements, seats, and usage. Both sections share one way of working.

Teams

Vitaly Slobodin (Senior Staff Fullstack Engineer) works across the section.

Stable counterparts are listed on the shared ways of working page.

CustomersDot engineering

Approving and merging

Every MR targeting main in CustomersDot needs at least one approval from someone other than the author.

• At least two reviewers, one of them a maintainer. Trivial MRs with no logic change (dependency bumps, test fixes, plain reverts) need one reviewer.
• A maintainer review is required.
• Follow the Danger bot suggestions. Database changes need database review, security sensitive changes need a Security review, Salesforce API changes need Sales Systems, Zuora API changes need Enterprise Applications, and user experience changes need a UX review.

Testing

CustomersDot runs linting, unit, integration, frontend, and E2E tests. The VCR flag mocks Zuora calls by default, and a daily scheduled pipeline runs against the Zuora sandbox to catch API changes. Failures block deployment to staging and production.

End-to-end tests live in GitLab and CustomersDot. Use CustomersDot only when the test needs the CustomersDot portal. See the CustomersDot E2E guide.

Deployment

CustomersDot uses continuous deployment. Merges to staging deploy to staging, run E2E tests, and auto deploy to production after 3 hours.

graph TD;
    A(Merged) --> |Green tests| B(Staging);
    B --> C[E2E tests on staging];
    C --> D[Verification];
    D --> E(Auto deploy to production in 3 hours);

• To stop a production deploy, open a non-confidential issue with the production::blocker label.
• To expedite a fix while a blocker is in place, unschedule the production job and trigger it manually after removing the label.
• Use feature flags for significant changes.
• Feature freeze matches the rest of GitLab, from the Friday the milestone ends to release day.
• During a Production Change Lock, open an issue with the PCL template listing DRIs and times for adding and removing production::blocker.
• Zuora has blocked periods where change requests need extra approval.

Revenue impacting changes

Our changes can directly impact revenue. PM is the DRI for high risk changes and takes input from Sales, Enterprise Applications, Marketing, Finance, and Support.

High risk examples: pricing, billing, launching or deprecating a paid feature, terms of service changes, and changes to how consumption is calculated or displayed. Low risk examples: backend changes not yet used by the frontend, and changes behind a feature flag or labeled beta or experimental.

For high risk changes:

• Update feature documentation and share it with stakeholders.
• Use confidential issues and the regular MR process.
• Ship behind a feature flag and create a rollout issue for the release date.
• Consider enabling for a subset of customers first.

Access review

EMs and section leadership review CustomersDot access quarterly following the access review process, based on role and department. Sales keeps read-only access. AppSec, Billing, Monetization and Fulfillment team members, IT Helpdesk, and Support keep write access. When in doubt, reject: access can be restored through an access request.

Operational monitoring

Recurring monitoring work is assigned to DRIs in each milestone planning issue and counts against capacity:

• Provision Tracking System failure monitoring
• Salesforce and Zuora Sentry monitoring

Trials

Growth owns trial entry points. Monetization and Fulfillment own the deeper trial codebase and all CustomersDot operational support. See the Trials Ownership and Collaboration Framework.

Architecture review

A weekly architecture review covers cross-group projects, CustomersDot architecture, and the Zuora integration. Everyone is welcome. Add topics to the agenda at least one day ahead. The meeting is cancelled if the agenda is empty.

Incident management

Escalation process for incidents or outages

Monetization runs a Tier 2 SME on-call rotation. The Engineer on Call escalates through incident.io:

1. Level 1: current SME on call (EMEA, AMER, or APAC).
2. Level 2: round robin to all rotation members if Level 1 does not acknowledge within 15 minutes.
3. Level 3: James Lopez.

On an outage, #customersdot_errors is notified and James Lopez and Vitaly Slobodin are paged automatically. The SRE on call can ping @fulfillment-engineering in Slack for help.

Urgent fixes

When production is broken, check whether Rapid Engineering Response applies. A maintainer can bypass the 3 hour staging to production wait with a manual deploy. Open an issue describing the escalation and announce it in #fulfillment_monetization_engineering.

Investigation

• Exceptions: Sentry
• Logs: Kibana
• Health checks: CustomersDot health, credentials in the Subscription portal 1Password vault
• Declare an incident for production outages or failed deploys.

Customer escalations

Licensing escalations from Support or Sales go through the support internal request process, not Slack. Leaders subscribe to the License Issue High ARR label.

Slack

Shared channels are listed on the ways of working page.

Links

• Shared ways of working
• Fulfillment Guide (CustomersDot admin and process docs)
• CustomersDot resource videos
• Performance indicators and engineering dashboards

View page source - Edit this page - please contribute.