48.3k Log in Get started
Dashboard

What goes in a failed payments dashboard in Metabase?

A failed payments dashboard surfaces the involuntary churn hiding in your billing data — payments that decline and the revenue you recover (or lose) through dunning. It's often the fastest recurring-revenue win because the customers still want the product. Build it from billing data synced into a database — seeStripe, Recurly, or Chargebee for the connection.

For: Finance, RevOps, growth. Refresh: daily — dunning is time-sensitive. Source: modeled charges/invoices with status, decline reason, and retry/recovery events.

Which cards belong on a failed payments dashboard?

Headline KPIs

  • Failed-payment rate
  • At-risk MRR — recurring revenue on failing subscriptions
  • Dunning recovery rate
  • Involuntary churn (MRR lost to failed payments)

Trend & breakdown

  • Failed vs. recovered payments by month
  • Decline reasons (insufficient funds, expired card, etc.)
  • Recovery by retry attempt number
  • At-risk accounts by MRR (table)

What data does a failed payments dashboard need?

  • A modeled charges/invoices table with status and timestamps.
  • Decline / failure reason codes.
  • Retry attempts and recovery timestamps for dunning performance.
  • A link to the subscription and its MRR for at-risk revenue.

How do you build a failed payments dashboard?

  1. Sync your billing tool into a database (Stripe, Recurly, or Chargebee).
  2. Model charges/invoices with a consistent status and join to subscriptions for MRR at risk.
  3. Flag recovered payments (a later success after a failure) to measure dunning.
  4. Create one card per metric; add filters for reason, plan, and date.

Example card SQL

Failed-payment rate and recovery by monthPostgreSQL
-- Failed-payment rate and dunning recovery by month.
SELECT
  date_trunc('month', c.created_at)                       AS month,
  COUNT(*)                                                AS charges,
  COUNT(*) FILTER (WHERE c.status = 'failed')             AS failed,
  ROUND(100.0 * COUNT(*) FILTER (WHERE c.status = 'failed')
        / NULLIF(COUNT(*), 0), 2)                         AS failed_rate_pct,
  ROUND(100.0 * COUNT(*) FILTER (WHERE c.recovered_at IS NOT NULL)
        / NULLIF(COUNT(*) FILTER (WHERE c.status = 'failed'), 0), 1)
                                                          AS recovery_rate_pct
FROM charges c
GROUP BY date_trunc('month', c.created_at)
ORDER BY month;

Integrations

Stripe + MetabaseRecurly + MetabaseChargebee + Metabase

Analytics

Revenue analyticsOverviewRevenue & billing overviewOverview

Dashboards

Churn & retention dashboardMRR / ARR dashboard

Metrics

Failed-payment rateChurn rateMRR

FAQ

What is involuntary churn?
Involuntary churn is recurring revenue lost when a payment fails and is never recovered — an expired card, insufficient funds, or a hard decline — rather than a customer choosing to cancel. It shows up on the churn dashboard too, but the fix lives here: better retries, card-update prompts, and dunning emails.
What's a good dunning recovery rate?
It depends on your retry logic and customer base, but well-tuned dunning commonly recovers a meaningful share of failed payments. Track recovery by retry attempt and by decline reason so you can see which failures are worth chasing and where smarter retry timing helps.
Why not just read this in Stripe?
Stripe shows failed charges, but modeling them in Metabase lets you tie failures to MRR at risk, blend multiple billing sources, segment by plan, and connect involuntary churn to the rest of your revenue reporting in one governed place.