Surface Pro active series and Stripe price tiers in usage#919
Draft
epompeii wants to merge 1 commit into
Draft
Conversation
The /usage endpoint now reports the Pro active-series count (the Pro billable figure) instead of an informational metrics figure, and JsonPlan carries the Stripe tiered price ladder so the Console renders prices from the billed source of truth rather than hardcoding them. * bencher_json: add JsonPriceTier and JsonPlan.tiers; add JsonUsage.active_series * bencher_billing: read the full tier ladder from the Stripe price (Products::price_tiers) and attach it in get_plan * api_organizations: count active series for Pro via series::count_active * Console: billing panel renders the current band, runner line, and full ladder from usage.plan.tiers; pricing table and FAQ move to the series-band model
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #918.
What
Two follow-ups to #918 (Pro plans billed on active time-series):
/usagesurfaces the Pro active-series count. Previously/usagereturned an informational metrics figure for Pro that no longer matched the bill. It now returnsactive_series(via the existingseries::count_active), the actual Pro billable figure.The Pro price ladder is read from Stripe, not hardcoded in the Console.
JsonPlannow carries the Stripe tiered price (tiers), read from the price the subscription is billed on. The billing panel renders the current band, the full ladder, and the base fee fromusage.plan.tiers/usage.plan.unit_amount, so what we display cannot drift from what we bill.The Console moves Pro from the old "$20 + $20 credit, $0.01/result" model to the series-band model:
Bare Metal runner minutes bill separately on top of the band fee, except during the first-month free trial (base waived plus runner minutes included = $0).
Changes
JsonPriceTier(up_to/unit_amount/flat_amount, the two amounts additive),JsonPlan.tiers,JsonUsage.active_series.Products::price_tiersmaps the Stripe price's full tier ladder to JSON;get_planattaches it.metered_plan_usagereturns active series for Pro (Team/Enterprise still on metrics); the Cloud branch is extracted intocloud_plan_usage.convert.tstier helpers (currentSeriesTier,seriesTierRange,fmtTierPrice,tierEstimateUsd, ...) overJsonPlan.tiers; a newProMeteredPanel;InnerPricingTableand thepricing.astroFAQ rewritten to the series-band model.openapi.jsonandbencher.ts.Tests
bencher_billing:to_json_tiermapping (flat-only, per-series-only, both, and the unbounded contact tier).convert.test.ts: tier helpers across all four price shapes plus the contact tier.api_organizationsusage endpoint tests andbencher_jsonbilling config tests still pass.series::count_active(oracle tests) andmetered_bills_active_series.Notes
TestServer(which covers the free and self-hosted paths)./pricingpage keeps "$100 / 250 series" as marketing copy, since it has no subscription context to read tiers from; fully de-hardcoding it would need a public pricing-catalog endpoint (follow-up).