How to build Stripe revenue dashboards in Metabase

Stripe is where your subscriptions, invoices, and payments live. 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 Stripe 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 Stripe to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Stripe connector. So connecting Stripe to Metabase means one thing: run a small pipeline that copies Stripe 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 Stripe 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 — upgrades, downgrades, and add-ons
• Failed payments and dunning — declines, recovery, and involuntary churn
• LTV and ARPU — value per customer and per account
• Cohort revenue — how each signup cohort retains and grows
• Cash and fees — gross vs. net after Stripe fees, refunds, and disputes

Which Stripe dashboards should you build in Metabase?

How do you build the Stripe → Metabase pipeline?

For dashboards that need history and reliability, land Stripe data in a database first, then connect Metabase to that database.

Connector options

• dlt (free, code) — a verified Stripe source for a Python pipeline when you want full control and a no-vendor sync.
• Stripe API (free, raw) — the source of truth; paginate objects and use event/webhook history for changes.
• Stripe Data Pipeline (first-party) — syncs your full Stripe data directly into Snowflake or Redshift, no third-party connector needed.
• Airbyte — has a Stripe source covering customers, subscriptions, invoices, charges, and more. Free if you self-host the open-source version; paid on Airbyte Cloud.
• Fivetran (paid, managed) — offers a Stripe connector with a maintained schema and incremental syncs.

Notes

• Land raw tables first, then build clean models on top.
• Stripe amounts are in the smallest currency unit (e.g. cents) — divide by 100 in your model layer, and handle zero-decimal currencies.
• Stripe timestamps are Unix epochs — convert with to_timestamp() once in a model.
• MRR is derived, not stored: build it from active subscription items and normalized prices.

Can you generate a Stripe dashboard with AI?

Yes — and once Stripe 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:

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 status

On 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 Stripe Revenue Overview dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

Create a polished Metabase dashboard for Stripe revenue analytics using the
available Stripe tables in this database.

Goal: Help founders and finance leaders understand recurring revenue, churn,
retention, failed payments, and cohort economics from Stripe data.

First, inspect the schema and identify the available Stripe tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Customers, Subscriptions, Subscription items, Invoices, Invoice
line items, Charges, Payment intents, Prices/Plans, Products, Refunds, Disputes,
and Balance transactions.

Important:
- Build the dashboard from durable database/warehouse tables.
- Compute MRR from active subscription items, normalizing every plan to a monthly
  amount (divide annual by 12, multiply weekly, etc.) and converting all amounts
  from the smallest currency unit (e.g. cents) to a major unit.
- 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, taxes, and refunds from MRR unless explicitly asked.
- Do not claim Metabase connects natively to Stripe unless that is explicitly
  true in this environment.

Dashboard title: Stripe 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 (waterfall
   or stacked bar); Net new MRR by month.
3. Churn & retention: Customer churn vs. revenue churn by month; Gross vs. net
   retention; Voluntary vs. involuntary churn.
4. Failed payments & dunning: Failed charges and $ at risk; Recovery rate after
   retries; Declines by reason; Past-due subscriptions by age.
5. Cohorts & LTV: Revenue retention by signup-month cohort; Cumulative LTV by
   cohort; ARPU by plan.

Filters: Plan/Price, Product, Billing interval, Currency, Country, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_stripe_customers, modeled_stripe_subscriptions, modeled_stripe_invoices,
modeled_stripe_charges, and modeled_stripe_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 the
Stripe Dashboard. Keep it practical, dense, and executive-readable. Avoid vanity
metrics.

How should you model Stripe data in Metabase?

Core tables

Modeling advice

• Build a modeled_stripe_mrr table: one row per subscription per month with a normalized monthly amount — the backbone of every revenue chart.
• Normalize all prices to a monthly figure (annual ÷ 12, etc.) and to a single reporting currency.
• Define subscription status once (active / trialing / past_due / canceled) and reuse it everywhere.
• Separate one-time charges from recurring invoice lines so they don't inflate MRR.
• Reconcile modeled MRR and revenue against the Stripe Dashboard before anyone trusts the numbers.

Which Stripe metrics should you track in Metabase?

What SQL powers Stripe dashboards in Metabase?

These assume the modeled tables above (PostgreSQL dialect, amounts in cents, epoch timestamps). Adjust identifiers to match your warehouse.

WITH monthly AS (
  SELECT
    si.subscription_id,
    -- normalize every price to a monthly amount, in major currency units
    SUM(
      CASE p.interval
        WHEN 'year'  THEN p.unit_amount / 100.0 / 12.0
        WHEN 'month' THEN p.unit_amount / 100.0
        WHEN 'week'  THEN p.unit_amount / 100.0 * 52.0 / 12.0
        WHEN 'day'   THEN p.unit_amount / 100.0 * 365.0 / 12.0
      END * si.quantity / NULLIF(p.interval_count, 0)
    ) AS mrr
  FROM subscription_items si
  JOIN prices p        ON p.id = si.price_id
  JOIN subscriptions s ON s.id = si.subscription_id
  WHERE s.status IN ('active', 'past_due')
  GROUP BY si.subscription_id
)
SELECT ROUND(SUM(mrr), 2) AS mrr_now,
       ROUND(SUM(mrr) * 12, 2) AS arr_now
FROM monthly;

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 s.created <= m.month
      AND date_trunc('month', s.canceled_at) = m.month
  ) AS churned_subscriptions,
  COUNT(*) FILTER (
    WHERE s.created <= m.month
      AND (s.canceled_at IS NULL OR s.canceled_at > m.month)
  ) AS active_at_month_start
FROM months m
CROSS JOIN subscriptions s
GROUP BY m.month
ORDER BY m.month;

SELECT
  date_trunc('week', to_timestamp(c.created)) AS week,
  COUNT(*)                                     AS failed_charges,
  ROUND(SUM(c.amount) / 100.0, 2)              AS dollars_at_risk,
  c.failure_code
FROM charges c
WHERE c.status = 'failed'
  AND to_timestamp(c.created) >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY 1, c.failure_code
ORDER BY 1, dollars_at_risk DESC;

What are common mistakes when analyzing Stripe in Metabase?

Related

Related analytics

Related metrics

Related integrations

FAQ