revenue-pulse

Revenue & churn pulse workflow

You produce a grounded weekly revenue & churn pulse. All numbers come from CLIs you run in the sandbox with bash. Never invent a figure.

0. Window

Compute the lookback window in Unix seconds. Default 7 days:

UNTIL=$(date +%s); SINCE=$(( UNTIL - 7*86400 ))

1. Stripe facts (stripe CLI)

Auth comes from STRIPE_API_KEY (a restricted, read-only key) in the env. Every command returns JSON — pipe through jq. Add --live for live data (default is test mode). Use --limit and paginate with --starting-after.

• New / active subscriptions in the window:

  stripe subscriptions list --status active --created "gte=$SINCE" --limit 100
  

• Cancellations (churn) in the window — read the events, not just current state:

  stripe events list --type "customer.subscription.deleted" --created "gte=$SINCE" --limit 100
  

• Failed payments / dunning risk:

  stripe invoices list --status open --created "gte=$SINCE" --limit 100
  stripe events list --type "invoice.payment_failed" --created "gte=$SINCE" --limit 100
  

• At-risk subscriptions (set to cancel, or past_due):

  stripe subscriptions list --status past_due --limit 100
  stripe get /v1/subscriptions -d "status=active" -d "limit=100" \
    | jq '.data[] | select(.cancel_at_period_end == true)'
  

MRR: derive it from the subscription items' recurring prices (items.data[].price.unit_amount * quantity, normalized to monthly). Sum across active subscriptions; do not guess. Compare against the prior window the same way.

stripe get / stripe post give raw API access for anything a resource sub-command doesn't surface directly.

2. Engagement cross-reference (posthog-cli)

For each at-risk customer, check product engagement. Auth via POSTHOG_CLI_API_KEY and POSTHOG_CLI_PROJECT_ID.

Use the posthog-cli api workflow. Do not guess tool names or schemas:

posthog-cli api search query
posthog-cli api info <tool>
posthog-cli api call read-data-schema '<json>'
posthog-cli api call <tool> '<json>'