How to build Chargebee revenue dashboards in Metabase
Chargebee runs your subscriptions, invoicing, and recurring billing. Metabase is where you turn that billing activity into shared, trustworthy dashboards. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync Chargebee into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector.
How do you connect Chargebee to Metabase?
Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Chargebee connector. So connecting Chargebee to Metabase means one thing: run a small pipeline that copies Chargebee data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.
The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.
What can you analyze from Chargebee data in Metabase?
- MRR and ARR — recurring revenue now and its monthly movement
- Churn and retention — customer and revenue churn, gross and net retention
- Expansion and contraction — plan changes, add-ons, and quantities
- Failed payments and dunning — declines, recovery, and involuntary churn
- Trials and conversion — trial-to-paid rate and time to convert
- LTV and ARPU — value per customer and per account
- Cohort revenue — how each signup cohort retains and grows
Which Chargebee dashboards should you build in Metabase?
MRR & ARR
The core recurring-revenue picture, month over month.
- MRR and ARR right now (number + trend)
- MRR movement: new, expansion, contraction, churn (waterfall)
- Net new MRR per month (bar)
- ARR by plan and billing period (bar)
Churn & retention
Where recurring revenue leaks and how well you keep it.
- Gross and net revenue retention by month (line)
- Customer vs. revenue churn rate (dual line)
- Cancellations by reason (bar)
- Trial-to-paid conversion rate (number)
Failed payments & dunning
Recover revenue lost to declines before it becomes churn.
- Failed transactions and $ at risk this month (number)
- Dunning recovery rate (line)
- Declines by gateway and error code (bar)
- Subscriptions in dunning by age (table)
Cohort revenue
Does each signup cohort grow or decay over time?
- Revenue retention by signup-month cohort (heatmap)
- Cumulative LTV by cohort (line)
- ARPU by plan and cohort (table)
- Expansion revenue by cohort (bar)
How do you build the Chargebee → Metabase pipeline?
For dashboards that need history and reliability, land Chargebee data in a database first, then connect Metabase to that database.
Connector options
- Chargebee API (free, raw) — the source of truth; write a small script that paginates objects and uses event history for changes. An AI assistant can scaffold it.
- Airbyte — has a Chargebee source covering customers, subscriptions, invoices, transactions, and more. Free if you self-host the open-source version; paid on Airbyte Cloud.
- Chargebee data exports (first-party) — scheduled exports and the Sync feature push billing data into your warehouse.
- Fivetran (paid, managed) — offers a Chargebee connector with a maintained schema and incremental syncs.
Notes
- Land raw tables first, then build clean models on top.
- Chargebee amounts are in the smallest currency unit — divide by 100 in your model layer.
- Chargebee timestamps are Unix epochs — convert with
to_timestamp()once in a model. - MRR is derived: build it from active subscriptions and their plans / item prices.
Can you generate a Chargebee dashboard with AI?
Yes — and once Chargebee data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.
Two ways to let an assistant query and build in Metabase
Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:
Metabase MCP
- Best for
- Chat clients (Claude, Cursor, Codex)
- Enable
- Admin → AI → MCP
- Endpoint
https://<your-metabase>/api/metabase-mcp- Auth
- OAuth handled by Metabase
Metabase CLI
- Best for
- Terminal agents, scripts, and CI
- Install
npm install -g @metabase/cli- Auth
- Browser OAuth (v62+) or an API key
- Docs
- @metabase/cli
Set up the Metabase MCP server
Enable it under Admin → AI → MCP, then point your client at the endpoint:
# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp{
"mcpServers": {
"metabase": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
}
}
}Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.
Set up the Metabase CLI
Install it globally, then authenticate once (the binary is mb):
# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli
# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth statusOn Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.
Prompt: build the Chargebee Revenue Overview dashboard
With MCP or the CLI connected, paste this into your assistant to generate the dashboard:
Create a polished Metabase dashboard for Chargebee revenue analytics using the
available Chargebee tables in this database.
Goal: Help founders and finance leaders understand recurring revenue, churn,
retention, failed payments, and cohort economics from Chargebee data.
First, inspect the schema and identify the available Chargebee tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Customers, Subscriptions, Subscription items, Plans/Item prices,
Invoices, Invoice line items, Transactions, Credit notes, and Payment sources.
Important:
- Build the dashboard from durable database/warehouse tables.
- Compute MRR from active subscriptions, normalizing every plan to a monthly amount
(divide annual by 12, etc.) and converting amounts from the smallest currency unit
where applicable.
- Report revenue in a single reporting currency; if multiple currencies exist,
convert with a documented rate or caveat the mix.
- Separate voluntary churn from involuntary (failed-payment) churn.
- Exclude one-time charges, add-on non-recurring lines, and taxes from MRR unless
explicitly asked.
- Do not claim Metabase connects natively to Chargebee unless that is explicitly
true in this environment.
Dashboard title: Chargebee Revenue Overview
Sections:
1. Executive summary (KPI cards): MRR; ARR; Active subscriptions; Net new MRR this
month; Gross revenue churn %; Net revenue retention (only if MRR-movement data
can be derived).
2. MRR movement: New, expansion, contraction, and churned MRR by month.
3. Churn & retention: Customer vs. revenue churn by month; Gross vs. net retention;
Cancellations by reason; Trial-to-paid conversion.
4. Failed payments & dunning: Failed transactions and $ at risk; Dunning recovery
rate; Declines by gateway/error; Subscriptions in dunning by age.
5. Cohorts & LTV: Revenue retention by signup-month cohort; Cumulative LTV by
cohort; ARPU by plan.
Filters: Plan/Item price, Billing period, Currency, Customer segment, Date range.
Before finalizing, create or recommend reusable Metabase models:
modeled_chargebee_customers, modeled_chargebee_subscriptions,
modeled_chargebee_invoices, modeled_chargebee_transactions, and
modeled_chargebee_mrr (a monthly per-subscription MRR model).
Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric that
cannot be calculated from the available schema. Reconcile totals against Chargebee's
RevenueStory. Keep it practical, dense, and executive-readable. Avoid vanity metrics.How should you model Chargebee data in Metabase?
Core tables
| Table | Grain | Key columns |
|---|---|---|
customers | one row per customer | id, email, created_at, auto_collection |
subscriptions | one row per subscription | id, customer_id, plan_id, plan_amount, plan_quantity, status, created_at, cancelled_at, next_billing_at |
plans / item_prices | one row per price | id, price, period, period_unit, currency_code |
invoices | one row per invoice | id, customer_id, subscription_id, status, total, amount_paid, date |
transactions | one row per transaction | id, customer_id, amount, type, status, error_code, date |
credit_notes | one row per credit note | id, customer_id, total, type, date |
Modeling advice
- Build a
modeled_chargebee_mrrtable: one row per subscription per month with a normalized monthly amount. - Normalize all plans to a monthly figure (annual ÷ 12, etc.) and to one reporting currency.
- Define subscription status once (active / in_trial / non_renewing / cancelled) and reuse it.
- Keep add-ons and one-time charges out of MRR unless they are genuinely recurring.
- Reconcile modeled MRR against Chargebee RevenueStory before anyone trusts the numbers.
Which Chargebee metrics should you track in Metabase?
| Metric | Definition | Notes |
|---|---|---|
| MRR | Sum of active subscriptions' normalized monthly amount. | Exclude one-time charges and tax. |
| Net new MRR | New + expansion − contraction − churned MRR. | Best shown as a monthly waterfall. |
| Revenue churn rate | Churned MRR ÷ MRR at period start. | Track separately from customer (logo) churn. |
| Net revenue retention | (Starting MRR + expansion − contraction − churn) ÷ starting MRR. | Over 100% means expansion beats churn. |
| Trial-to-paid conversion | Trials that became paying subscriptions ÷ trials started. | Watch time-to-convert too. |
| Failed-payment rate | Failed transactions ÷ attempted transactions. | The main driver of involuntary churn. |
| LTV | ARPU × average customer lifetime (1 ÷ churn rate). | Sensitive to churn; treat as a range. |
What SQL powers Chargebee dashboards in Metabase?
These assume the modeled tables above (PostgreSQL dialect, amounts in the smallest currency unit, epoch timestamps). Adjust identifiers to match your warehouse.
Normalize active subscriptions to a monthly amount and sum.
SELECT
ROUND(SUM(
CASE p.period_unit
WHEN 'year' THEN s.plan_amount / 12.0 / NULLIF(p.period, 0)
WHEN 'month' THEN s.plan_amount / NULLIF(p.period, 0)
WHEN 'week' THEN s.plan_amount * 52.0 / 12.0 / NULLIF(p.period, 0)
END * s.plan_quantity
) / 100.0, 2) AS mrr_now
FROM subscriptions s
JOIN plans p ON p.id = s.plan_id
WHERE s.status IN ('active', 'in_trial', 'non_renewing');Cancellations against subscriptions active at each month's start.
WITH months AS (
SELECT generate_series(
date_trunc('month', CURRENT_DATE - INTERVAL '11 months'),
date_trunc('month', CURRENT_DATE),
INTERVAL '1 month'
) AS month
)
SELECT
m.month,
COUNT(*) FILTER (
WHERE date_trunc('month', to_timestamp(s.cancelled_at)) = m.month
) AS churned_subscriptions,
COUNT(*) FILTER (
WHERE to_timestamp(s.created_at) <= m.month
AND (s.cancelled_at IS NULL OR to_timestamp(s.cancelled_at) > m.month)
) AS active_at_month_start
FROM months m
CROSS JOIN subscriptions s
GROUP BY m.month
ORDER BY m.month;Declined transactions by week and error code — the dunning worklist.
SELECT
date_trunc('week', to_timestamp(t.date)) AS week,
COUNT(*) AS failed_transactions,
ROUND(SUM(t.amount) / 100.0, 2) AS dollars_at_risk,
t.error_code
FROM transactions t
WHERE t.status = 'failure'
AND to_timestamp(t.date) >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY 1, t.error_code
ORDER BY 1, dollars_at_risk DESC;