Setting the file. One moment.
Skill 155 · Understanding Billing Usage
Subchapter 155.2
references/usage-type-routing.mdMarkdown14 KBView on GitHub
Billing tools tell you the usage type, project, date range, and optional spend. Use this reference to choose the customer-visible product surface for the next step.
Do not query internal Billing tables or PostHog-owned telemetry when answering a customer-facing usage question. If the product-specific tools are not available, stop at the Billing evidence and say what the user can inspect in the UI.
When another product has a focused investigation skill, use it only after Billing has identified the usage type, affected project, and time window. The Billing investigation should stay responsible for the billable usage framing; the downstream skill should explain the product-level driver.
Useful downstream skills for usage investigations include:
posthog:investigate-metric for Product Analytics trend/event/funnel-style changes.posthog:exploring-autocapture-events when $autocapture is the likely event driver.posthog:investigating-error-issue after Error Tracking has identified a dominant issue.posthog:investigating-replay when Session Replay drilldown has representative recordings.posthog:auditing-warehouse-source-health and posthog:diagnosing-failed-warehouse-syncs
for Data Warehouse source or sync issues.posthog:investigating-logs for Logs ingestion spikes or drops.posthog:exploring-llm-costs and posthog:analyzing-expensive-users for AI
Observability spend or credit drivers.posthog:inbox-exploration for Signals/Inbox report-level drivers, with posthog:signals
only when the curated report layer is not enough.posthog:exploring-replay-vision-observations when Replay Vision credits point to scanner
observations.| Usage type | What Billing can show | Customer-visible follow-up |
|---|---|---|
event_count_in_period | Events by day/project | Use posthog:investigate-metric or Product Analytics SQL/insight tools on the affected project. Break down by event name and compare the alert/high-usage day to baseline days. If $autocapture dominates, continue with posthog:exploring-autocapture-events. |
enhanced_persons_event_count_in_period | Identified events by day/project | Start like Events, using posthog:investigate-metric when available, but avoid claiming the raw event-name breakdown exactly explains the identified/anonymous split unless that dimension is visible. |
group_analytics | Group Analytics spend/usage attribution using identified-event usage | Treat as an alias-style product view. Use identified-event/Product Analytics drilldown, usually via posthog:investigate-metric, and explain that the Billing view is product-specific attribution, not a separate raw event stream. |
recording_count_in_period | Session recordings by day/project | Use Session Replay tools or the Replay UI for recording volume, SDK/platform filters, and representative sessions. Use posthog:investigating-replay only after you have representative recording/session IDs. |
mobile_recording_count_in_period | Mobile recordings by day/project | Use Session Replay/mobile replay surfaces. Look for mobile SDK/platform mix before suggesting product changes. Use posthog:investigating-replay only after you have representative mobile recording/session IDs. |
billable_feature_flag_requests_count_in_period | Feature flag requests by day/project | Use feature flag tools, flag configuration, and activity history. The billable unit is flag evaluation/API request volume, not $feature_flag_called events. Do not use stale-flag cleanup workflows unless the user asks how to remove unused flags. |
exceptions_captured_in_period | Exceptions by day/project | Use Error Tracking issue tools and $exception aggregates in the affected project. If one issue dominates the movement, use posthog:investigating-error-issue. UI issue counts are grouped context, while Billing usage is captured exception volume. |
survey_responses_count_in_period | Survey responses by day/project | Use survey tools and survey events such as survey shown and survey sent to distinguish reach from response-rate changes. Use posthog:debugging-surveys when the investigation turns into “why is this survey showing, not showing, or getting fewer/more responses than expected?” |
ai_event_count_in_period | AI Observability events by day/project | Use AI Observability tools or SQL over $ai_* events in the affected project. Break down by provider/model/trace/user only when those properties are available. Use posthog:exploring-llm-costs for cost-shaped questions and posthog:analyzing-expensive-users for user-level drivers. |
ai_credits_used_in_period | PostHog AI credits by day/project | Use PostHog AI or AI Observability surfaces exposed to the user. Prefer posthog:exploring-llm-costs for credit/spend movement and posthog:analyzing-expensive-users for concentrated user drivers. Do not inspect internal PostHog-owned AI telemetry in a customer-facing investigation. |
signals_credits_used_in_period | Inbox credits by day/project | Use Signals/Inbox product tools when available. Start with posthog:inbox-exploration for report-level context; use posthog:signals only when raw signal search is needed. Billing shows chargeable credit movement; product tools should explain reports/PRs/refunds. |
posthog_code_credits_used_in_period | PostHog Desktop credits by day/project | Use PostHog Desktop usage surfaces when available. Treat token credits and sandbox compute as possible sub-drivers if exposed. |
posthog_code_token_credits_used_in_period | PostHog Desktop token credits by day/project | Use PostHog Desktop/AI usage surfaces when available. |
sandbox_compute_credits_used_in_period | Sandbox compute credits by day/project | Use task/sandbox/PostHog Desktop surfaces when available. |
sandbox_compute_cpu_millicore_seconds_in_period | Sandbox CPU usage by day/project | Use task/sandbox surfaces when available. This is a raw usage diagnostic, not usually the headline spend type. |
sandbox_compute_memory_mib_seconds_in_period | Sandbox memory usage by day/project | Use task/sandbox surfaces when available. This is a raw usage diagnostic, not usually the headline spend type. |
rows_synced_in_period | Data Warehouse synced rows by day/project | Use Data Warehouse source/schema health and sync tools. Look for new sources, enabled schemas, failed/stale syncs, or expected backfills. Use posthog:auditing-warehouse-source-health for a project-wide scan and posthog:diagnosing-failed-warehouse-syncs for a specific source/schema. |
free_historical_rows_synced_in_period | Historical synced rows by day/project | Use Data Warehouse source/schema tools. Explain it as historical sync activity, not ongoing incremental volume. Use posthog:auditing-warehouse-source-health or posthog:diagnosing-failed-warehouse-syncs if a source or schema needs investigation. |
rows_exported_in_period | Batch export rows by day/project | Use batch export/CDP export tools and export configuration. Check newly enabled exports or changed destinations. |
data_pipelines | Legacy Data Pipelines product attribution | Treat as a legacy/synthetic product view. Use the Product Analytics or CDP surface that actually produced the usage, depending on the user’s context. |
cdp_billable_invocations_in_period | Realtime destination trigger events by day/project | Use CDP function tools: list functions, inspect enabled destinations, metrics, and logs for the affected window. |
workflow_emails_sent_in_period | Workflow emails by day/project | Use Workflows tools: workflow stats, invocation logs, enabled workflows, and recent changes. |
workflow_billable_invocations_in_period | Workflow destination dispatches by day/project | Use Workflows tools and destination/invocation logs. Keep it separate from email volume. |
logs_mb_in_period | Logs ingested in MB by day/project | Use posthog:investigating-logs with Logs tools: service overview, count ranges, facets, and pattern diffs. Prefer log-specific tools over raw SQL. |
logs_retention_30d_mb_in_period | Logs ingested under 30-day retention by day/project | Use posthog:investigating-logs with Logs tools and retention/settings surfaces. Explain that this is retention-tier usage, not separate log content. |
logs_retention_mb_days_in_period | Logs retention in MB-days (bytes ingested weighted by retention days) by day/project | Use posthog:investigating-logs with Logs tools and retention/settings surfaces. Explain that this is storage-duration usage (MB times days retained), not separate log content. Average retention days = this / logs_mb_in_period. |
replay_vision_credits_used_in_period | Replay Vision credits by day/project | Use Replay Vision scanner/observation tools. Credits come from scanner observations, so inspect scanners and observation status/results. Use posthog:exploring-replay-vision-observations when scanner observations are the natural drilldown. |