21.2 Readiness cost metering

[determined-001]

Labels: type:feature area:workers type:ops
Milestone: Phase 4 - Workers W3: backstop
Effort: Medium
Depends on: 21.1

Description

§C.7 is explicit: model the readiness cost before pricing, because it is not pure
margin. Monitoring cost scales with the number of backstopped subscriptions
regardless of how many ever need intervention.

Meter it: RPC calls, export scans, compute and storage attributable per
subscription per window. Without this, the pricing page in 21.3 is a guess and
the product's margin is discovered in a monthly bill.

Acceptance criteria

• Per-subscription cost attribution for RPC calls, export scans, compute time
  and storage
• Aggregated cost per subscription per window, queryable over time
• Marginal cost of one additional backstopped subscription reported explicitly
• Metrics exported through the existing Prometheus and OTel surfaces
• A dashboard or documented query showing cost against subscription count
• Written cost model in docs/design/ with the measured numbers, not estimates

Implementation notes

1. Reuse the metrics interfaces in packages/pulse-webhooks/src/metrics.ts,
   PrometheusWebhookMetrics.ts and OtelWebhookMetrics.ts - one metrics idiom
   across the project.
2. Report marginal cost, not just total. Total cost hides the shape of the curve,
   and the shape is what decides whether the tier is viable at scale.
3. Shared monitoring across subscriptions watching the same condition is the main
   lever; measure before optimizing it.

Affected files

• packages/worker-core/src/backstop/costMeter.ts
• packages/worker-core/src/metrics.ts
• docs/design/backstop-cost-model.md

[DevTobis]

@DevTobis has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, I would like to work on this issue. I will implement per-subscription cost attribution in costMeter.ts covering RPC calls, export scans, compute time, and storage per window, aggregate the totals into queryable per-subscription per-window records, and report the marginal cost of one additional backstopped subscription explicitly so the pricing page in 21.3 is grounded in measured numbers rather than estimates. I will export all metrics through the existing Prometheus and OTel surfaces by reusing the interfaces in pulse-webhooks/src/metrics.ts rather than introducing a second metrics idiom, and document a dashboard query or written query showing cost against subscription count so the relationship between scale and margin is visible at a glance. I will write the full cost model in docs/design/backstop-cost-model.md with the actual measured figures including the marginal cost curve shape, since the shape is what determines whether the tier is viable at scale and total cost alone hides it. Can I be assigned?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @DevTobis to this issue.

[drips-wave]

Congratulations, @DevTobis! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @DevTobis: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[DevTobis]

Blocked, not abandoned — draft PR #1114 carries the design and states exactly what cannot be done yet.

The block is structural: packages/worker-core has no tracked files in this repo (git ls-files packages/worker-core returns nothing), and every file this issue names lives inside it. Its stated dependencies are also still open.

Closing per the maintainer's direction so the board reflects reality rather than showing work as in-flight when it cannot start. Reopen when the blockers land and I will convert the draft into a full implementation.

[DevTobis]

Draft PR #1114 opened with the design and an explicit statement of what cannot be done yet.

The block is structural. packages/worker-core has no tracked files in this repository — git ls-files packages/worker-core returns nothing, so the package does not exist. Every file this issue names lives inside it. The stated dependencies are also still open.

Implementing here would mean inventing that package's foundations, which 21.1 (#1062) will also define — two independent inventions of the same thing, and a guaranteed conflict.

I was asked to close this issue as well, but I don't have write access to this repo, so that has to be done by a maintainer. The draft PR is ready to review in the meantime, and I'll convert it to a full implementation once the blockers land.