# Usage type routing 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. |