Track dunning recovery from failed invoices

Measure failed-payment recovery from invoice failure through retry, card update, recovery, or cancellation for subscription revenue.

Updated · published

markdown for agents →

difficulty intermediate · time to value 5 minutes · execution on demand
#analytics #revenue #stripe #dunning #churn #saas

Start from this 

Build a dunning recovery funnel: invoice failed → retry scheduled → payment method updated → payment recovered or subscription canceled.

Why this matters

Failed payments are often recoverable churn. A dunning funnel shows whether users update cards, retries recover revenue, or accounts silently cancel.

What you get

  • Recovery rate after failed invoices
  • Time to recovery
  • Cancellations after dunning
  • Revenue at risk and recovered

Walk through it

You

How effective is our dunning flow?

Agent

I’ll stitch billing webhook events into a recovery funnel.

Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT event, count(DISTINCT properties.invoice_id) AS invoices, sum(toFloat(properties.amount)) AS amount FROM events WHERE event IN ('invoice_payment_failed','payment_method_updated','invoice_payment_recovered','subscription_canceled') AND timestamp > now() - INTERVAL 60 DAY GROUP BY event ORDER BY invoices DESC"

The output

The agent returns recovery rate, lost revenue, and suggested actions such as improving retry timing or card-update emails.

Setting it up

Emit billing lifecycle events from Stripe or your subscription provider webhook handler.

Variations

  • “Segment recovery by plan.”
  • “Find accounts with repeated payment failures.”
  • “Draft a Slack digest for at-risk revenue.”

Related workflows

debugging 2 minutes

Diagnose Stripe `card_declined` patterns

Group Stripe payment failures by decline_code. Surface the top causes and the customers affected. Different decline = different fix.

growth 15 minutes

Identify behavioral churn-risk signals

Compare pre-renewal behavior for retained and canceled customers, quantify associations, and prepare a reviewed risk hypothesis without claiming prediction.

growth 3 minutes

Track trial-to-paid conversion by acquisition source

Build the trial-to-paid funnel split by acquisition source. Surface the channel that converts 8x better than the rest.

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.
← all workflows