Show non-billable usage on the GitLab Credits dashboard chart

What does this MR do and why?

Shows non-billable GitLab Credits usage on the daily credits chart of the wallet-agnostic GitLab Credits dashboard, stacked next to billed usage and labeled by skip reason. Both dashboards use this frontend:

  • GitLab.com group dashboard (/groups/:group/-/settings/gitlab_credits_dashboard)
  • Self-managed instance dashboard (/admin/gitlab_credits_dashboard)

Frontend (ee/app/assets/javascripts/usage_quotas/wallet_agnostic_credits_dashboard):

  • New get_subscription_non_billable_usage.query.graphql for subscriptionUsage.nonBillableUsage (@gl_introduced(version: "19.5.0")), with the same date range and flowTypes filters as the overview query.
    • It runs as a separate Apollo query, so a failure (CustomersDot returns nonBillableUsage: null + nonBillableUsage is temporarily unavailable) never blanks the billed dashboard. The overview query uses the default errorPolicy: 'none'. On error it logs to console/Sentry and the chart renders billed usage only.
    • fetchPolicy: 'no-cache': both queries read the same un-normalized subscriptionUsage field, so caching this one would overwrite the overview query's cached result.
    • Entries whose productId isn't in products are dropped, so usage of products hidden on the instance (for example, flag-gated products) doesn't appear.
  • credits_consumption_chart.vue:
    • The existing series is renamed to Billed usage.
    • Adds one stacked series per skip reason, summed across products per date. Colors use the Pajamas data-viz hues at step 500.
    • Shows Non-billable: X credits next to the billed total. The billed total and the usage cards are unchanged, so they still reconcile with Customers Portal.
  • Skip reason labels (index/constants.js):
    • orbit_promo → Promotional
    • beta → Beta
    • internal → Internal
    • null → No reason provided
    • Any other value → Other non-billable

Backend: SubscriptionUsage#daily_usage now defaults limit to every day in the date range instead of min(30, days in range).

  • Before this change, on any range longer than 30 days the billed series stopped after the first 30 days with usage, while nonBillableUsage.dailyUsage covered the full range. That made long ranges look like there was no billed usage at all.
  • It also fixes the Peak day usage card, which was computed from the truncated series.
  • An explicit limit is still validated as before.
  • No schema change; only the limit argument's description is updated.

Raised in review: !260029 (comment 3965037161)

References

Screenshots or screen recordings

Scenario Screenshot
Group Dashboard

image.png

Screenshot 2026-10-07 at 11.50.42 AM.png

Group Dashboard

max possible range from date selector

Screenshot 2026-10-07 at 11.50.59 AM.png

Group Dashboard with No reason provided split

Screenshot 2026-10-07 at 12.10.26 PM.png

Self Managed Admin Dashboard

Screenshot 2026-10-07 at 12.31.51 PM.png

Self Managed Admin Dashboard with

max possible range from date selector

Screenshot 2026-10-07 at 12.32.03 PM.png

How to set up and validate locally

  1. Run CustomersDot locally on the branch from https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/17365, connected to your GDK (gdk config set license.customer_portal_url http://localhost:5000, then gdk reconfigure).
  2. Have usage for a GitLab Credits subscription in usage_billing_enriched, including some events with SkipConsumption = true, with and without skip_reason in Metadata.
  3. Make sure wallet_agnostic_credits_dashboard is enabled.
  4. Group dashboard: with GITLAB_SIMULATE_SAAS=1 and a paid group linked to the subscription, visit /groups/<group>/-/settings/gitlab_credits_dashboard.
  5. Instance dashboard: with GITLAB_SIMULATE_SAAS=0 and a self-managed license from your local CustomersDot for the subscription, visit /admin/gitlab_credits_dashboard.
  6. Check that:
    • Non-billable usage appears as stacked series per skip reason, and Non-billable: X credits shows next to the total.
    • A custom range longer than 30 days shows billed bars across the whole range.
    • The Products filter applies to both series.
    • Usage of a product hidden from products doesn't appear.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Harsh Vardhan Sharma

Merge request reports

Loading
Loading