Cloud Cost Explorer

telemetrySplunk index=propresenter-v2, a 10% random sample of active orgs (organization_id % 10 == 0), trailing 90 days (Jun 14 – Sep 12, 2026), pulled as three 30-day slices. Machine-level figures (media/show bytes, file counts, theme count, active days) come from unsampled telemetry events. n≈11,379 machines, 6,806 orgs.

not measuredLocal ProPresenter has no concept of "multiple cloud workspaces per org" yet, so Splunk can't measure it. Median = 1, Mean = 2, P95 = 3 workspaces/org are placeholder assumptions bundled with each profile — replace once ProPresenter Cloud has real onboarding data.

unconfirmed rateedit_presentation passes through a Splunk ingest-time sampling rule (propresenter-v2_samping). The exact rate couldn't be confirmed this session (Splunk's rest command is blocked for this connector). Edits/machine/month uses the raw 3-day sampled rate × a 10x correction factor, matching the documented historical ~10% sampling rate for high-volume events — directional, not exact.

not measuredSplunk gives point-in-time snapshots, not a month-over-month delta, so "new media / month" has no measured value.

calibratedAvg Worker CPU/request (0.94ms) and Avg DO duration/request (400ms) come from real Cloudflare billing (metabase_cloudflare_billing, Jul 17 – Sep 17 2026, two periods blended): 121,455,245 Worker CPU-ms ÷ 128,756,245 requests ≈ 0.94ms/request; 338,978.9 DO GB-s ÷ 6,710,949 DO requests ≈ 0.0505 GB-s/request, which implies ≈400ms/request at the standard 128MB DO memory allocation (billing bundles duration × memory into GB-s, so this assumes 128MB — adjust the memory slider if your DOs are configured larger). Same small early-beta account (~62 orgs) caveat applies as elsewhere.

modeling decisionToday's local ProPresenter workspaces are independent per machine — nothing is shared between machines yet. This model treats one machine's whole local workspace as what gets mirrored to one Cloud workspace, while the number of machines syncing to that workspace (from the assigned profile) drives fan-out cost multiplicatively — every applied edit broadcasts to N-1 other devices. An org's total footprint is that per-workspace cost × its workspace count.

methodologyFree-tier allowances and the $5/mo base fee are shared at the whole-product level (Cloudflare doesn't grant them per customer), so each tier's dollar cost above is its proportional share of each service's usage, applied to the post-free-tier bill for that service. Customer prices are placeholders you set — not a pricing decision Claude made.

modeling decisionCloudflare's SQLite-backed Durable Objects bill storage (GB-months) separately from requests and compute duration. DocumentDO's cached CRDT snapshot (snapshot_chunks) is transient, not a durable mirror of R2 — it's cleared by dropCachedSnapshot and offload paths in document.do.ts once a migration promotes or a document goes cold. The durable SQL storage is WorkspaceDO's documents metadata table (one row per document — document_id, version_vector, size_bytes, timestamps) plus migration-protocol tables, so this model estimates DO SQL storage as document count × an editable KB-per-document-row figure (default 5 KB, uncalibrated), not a function of document byte size. On a real production account's Aug 2026 billing cycle, DO SQL Storage was $1.20 of a $1.65 DO bill (72.7%) — larger than DO compute, which was fully covered by the free tier that cycle. Adjust the KB-per-document slider under "Technical estimates" once you have a real docCount-to-GB-months data point to calibrate against.

modeling decisionReal billing (metabase_cloudflare_billing) shows Container Memory + Disk as the account's 3rd-largest Cloudflare cost line, and Observability/Logs as a real, separate charge — neither was in earlier versions of this model. Containers back the ApplyContainer (loro-apply-service): reading document.do.ts's apply-retry path shows it's invoked per patch apply on a document flagged needs_offload (oversized) or that exhausts isolate memory mid-apply — a recurring per-edit cost, not a one-time upload charge and not involved in downloads at all. Modeled as: monthly applies × a per-profile "% of documents needing Container processing" (Profiles table, unmeasured placeholder) × an avg document-size estimate (Technical estimates, also unmeasured) = GB of large-document content processed, converted to GiB-seconds/GB-seconds via fixed multipliers sourced from a wrangler.jsonc code comment (~4x memory, ~1x disk, assuming a ~1s apply) — not back-solved from real billing, since real billing doesn't break Container cost out by document size or count the way it does for DO requests. Observability is modeled as log events per Worker request (real billing calibrated), since every worker in the stack has "observability": true and "logpush": true set. Same small early-beta account (~62 orgs) caveat applies throughout, and production's wrangler.jsonc declaring no containers block at all — while real production billing shows nonzero Container cost — is still an open discrepancy worth reconciling with engineering.

openA server-side Splunk aggregate of machines-per-org returned 9,293 machines for the sample window, while the raw per-machine pull used throughout this model counted 11,379–11,656. The discrepancy wasn't root-caused given session time constraints — worth resolving before this model informs a funding or pricing decision.