Turn PostHog event and recording counts into real cost
PostHog meters Product Analytics by the event and Session Replay by the recording, and the spend it totals for you stops at PostHog, in PostHog's own console. Here's how the billing works, and how to fold PostHog into one running cost and forecast across your whole stack while there's still time to act.
PostHog charges for understanding your own product. Every pageview it captures, every click it autocaptures, every session it records draws down an allowance, and once you pass that allowance the volume starts to cost. It's a fair way to bill for a tool that scales with how much you ship. The catch isn't PostHog's meter — it's that PostHog prices PostHog, in its own console, while every other tool you run prices itself somewhere else. So the question that matters as the month runs — what all of it costs together, PostHog folded in — has no single place that answers it until the invoices land.
PostHog already keeps the counts underneath that, product by product and day by day. The work left is pricing them into a running cost and a forecast before the month closes on you.
How does PostHog bill for usage?
PostHog’s pricing is usage-based, and the most important thing to know about it is that each product is metered separately, with its own free monthly allowance before anything is charged. You don’t buy a seat or a flat plan that bundles everything; you pay for what each product ingests or stores, past a generous free tier, and you can set a spend limit on each one. The two products that most often drive a developer’s bill are Product Analytics and Session Replay; if you’re shipping anything LLM-backed, LLM analytics (“AI Observability”) is a third. This guide covers all three.
Product Analytics
is billed by the event. Every event your project ingests counts —
pageviews, the clicks and form interactions PostHog autocaptures, the
identify calls that attach a person to a session, and any custom events
you send. The first 1 million events each month are free; past that,
events are metered by volume. Whether you cross that line depends on your
traffic and how many events each visit fires — PostHog
documents how to estimate your monthly volume
if you want to project it ahead of time. One wrinkle matters for reading your bill: events
tied to an identified person carry an extra charge on top of the base
rate — they show up on your invoice as Person Profiles — so two
projects ingesting the same number of events can bill differently
depending on how many of those events are identified.
Session Replay is billed by the recording, not by storage size. Each session your project records counts as one unit against a separate free monthly allowance — the first 5,000 web recordings each month are free, with mobile session replay on its own lower allowance — and recordings past it are metered. Because a single noisy page or an over-broad recording rule can multiply how many sessions you capture, replay volume can climb quickly and independently of your event volume — which is why PostHog gives you controls over which sessions get recorded.
LLM analytics — PostHog’s AI Observability — is metered separately again. When you instrument an AI feature, each model call PostHog captures arrives as an event (a generation, and the spans around it), and those are billed on their own allowance: the first 100,000 of them each month are free, then they’re metered per event — a line entirely apart from your Product Analytics events, even though they flow through the same pipeline. If you’re shipping anything LLM-backed, this is the meter that can climb while your pageview count sits still.
Those three aren’t everything PostHog meters. It also bills Feature Flags and Experiments (billed together), Surveys, and a Data Warehouse, each with its own free allowance. CostCompass tracks the three that PostHog surfaces through the query API it reads — Product Analytics, Session Replay, and LLM analytics — and prices each on the right meter; Feature Flags, Surveys, and the Data Warehouse aren’t available the same way, so the guide is honest about leaving them out.
| What you’re paying for | How PostHog meters it |
|---|---|
| Product Analytics events | Per event ingested, past 1 million free events each month |
| Identified events | An extra per-event charge on top of the base rate (Person Profiles) |
| Session Replay recordings | Per session recorded, past 5,000 free web recordings each month |
| LLM analytics events | Per generation/span event, past 100,000 free events each month |
| Each other product | Its own free allowance (feature flags, surveys, data warehouse…) |
(The exact allowances and per-unit rates live on PostHog’s pricing page and have been revised before, so treat any figure you’ve memorized as provisional.)
Why is PostHog spend hard to keep ahead of?
The per-event model is easy to reason about for a single event and hard to stay ahead of across a month. Most of the difficulty comes down to the gap between the volume PostHog shows you and the money it eventually charges:
- Counts aren’t cost. A usage page that says you’ve ingested a few million events is telling you the truth and answering the wrong question. Turning that into money means knowing the per-event rate, where your free allowance ends, and how many of those events are identified — arithmetic you end up doing in your head, if you do it at all.
- The free allowance hides the cliff. Usage inside each product’s monthly allowance costs nothing, so spend reads as zero — right up until you cross the line and every further event or recording is metered. A running count doesn’t mark where that line sits.
- Identified events cost more, quietly. Because identified events
carry the Person Profiles surcharge, a release that starts calling
identifymore often can move the bill without changing your raw event volume much at all. - Replay climbs on its own. Session Replay is metered separately and is easy to over-capture — widen a recording rule or ship a chatty page and your recording count jumps while your event count holds steady. Each product spends on its own meter, independently.
- PostHog is rarely your only provider. Alongside it you’re likely calling Anthropic for Claude, building on OpenAI or Google, and paying for inference hosts and serving, so PostHog is one slice of a bill you otherwise stitch together by hand from a stack of dashboards, each counting in its own units.
Is the PostHog cost exact or estimated?
Some providers hand back a cost figure they’ve already worked out. PostHog’s query API hands back counts — events ingested and recordings stored — and leaves the costing to you, so the PostHog number in CostCompass is an estimate, marked as such, and not read off a settled invoice.
CostCompass prices those counts the way PostHog’s own meter does. It applies the volume tiers — the per-unit rate that steps down as monthly volume grows — and the free monthly allowances that cover your first slice of usage before anything is billed. It splits identified events (your bill’s Person Profiles) from anonymous ones, because PostHog charges far more for the identified ones. And it keeps web and mobile recordings apart, since each carries its own free allowance and its own rate. What still keeps it an estimate rather than your invoice: PostHog’s published rates can differ from a negotiated plan, and the figure is built from the counts PostHog reports for the window CostCompass fetched, not reconstructed from your exact billing cycle. Treat it as a working estimate you can act on as the month runs, not the final invoice.
How can you reduce your PostHog bill?
Tracking shows you where the events and recordings go; a few levers slow the burn:
- Sample high-volume events. If a handful of event types dominate your ingestion, sampling them or dropping ones you never query is usually the single biggest lever on Product Analytics spend.
- Tighten what you record. Session Replay bills per recording, so scoping your recording rules — capturing the sessions you actually review rather than every visit — keeps the recording count, and the charge, down.
- Watch identified events. Because identified events carry the Person
Profiles surcharge, calling
identifyonly where you need a person attached — rather than on every anonymous hit — keeps the priced volume honest. - Set per-product spend limits. PostHog lets you cap spend on each product independently, so a runaway page can’t quietly run your whole bill up.
- Watch the per-product split. A by-product view catches a replay spike or an ingestion climb in days, while the month-end total would only show it once it’s already been paid.
How do you forecast next month’s PostHog bill?
Forecasting usage-based spend doesn’t need anything exotic, just a burn rate: take your cost over the last several days, turn it into a daily average, and project it across a full month.
CostCompass does exactly this. It scales your trailing seven-day burn rate to the number of days in next month, and the result is one forward number for what next month costs if the current pace holds. Seven days is the window — long enough that one heavy ingestion day doesn’t throw the average, short enough to pick up a recent change like a release that started recording far more sessions. Because the usage is priced consistently, the projection rides on your tracked spend, and it’s the same engine that runs across every provider you’ve connected, so PostHog folds into one whole-stack number.
How does CostCompass track your PostHog costs?
CostCompass connects to PostHog Cloud — US or EU, detected when you connect — with a personal API key and runs two read-only queries against your project: a daily count of ingested events — split into identified, anonymous, and LLM-analytics events — and a daily count of session recordings, split into web and mobile. It prices those counts into money against PostHog’s tiered rates, each on its own meter, treating usage inside each product’s free allowance as covered and the rest as metered, and records the result as an estimate. That gives you what a raw count can’t: which product spent what, in money, day by day, across Product Analytics, Session Replay, and LLM analytics. When you first connect, CostCompass pulls a recent window of usage rather than your whole history, and each refresh brings the running total current — the moment you click Refresh, not on some schedule behind your back.
Two things make that practical for a solo developer. First, your key is encrypted in your browser before anything is stored. The API key you paste is sealed with your vault password on your own device, and only the sealed version is ever saved — a blob CostCompass can’t open, because the vault password stays with you. When it’s time to read your usage, your browser unseals the key and passes it to a relay that uses it for that one call to PostHog and is built not to log or keep it. What we hold at rest is locked ciphertext; the key your project runs on never reaches us in usable form.
Second, PostHog doesn’t sit alone. The same dashboard rolls its running cost up with every other AI and compute provider you’ve connected — Claude, OpenAI, your GPUs and hosting — into one figure with a forecast. How you get to that cross-provider number — by hand, through tooling, or read straight from each usage API — is its own decision; the ways to track AI costs across providers lay the options out side by side.
| PostHog’s billing page | CostCompass | |
|---|---|---|
| Scope | PostHog spend alone | PostHog beside every other provider |
| Forecast | Projects PostHog’s spend only | One forecast across your whole stack |
| Lives in | PostHog’s own console | One dashboard with all your spend |
| Currency | Updates on PostHog’s billing cycle | Current the moment you click Refresh |
Getting started takes three steps:
- In PostHog, create a personal API key with the
query:readandsession_recording:readscopes, on the project you want to track. - Paste it into CostCompass. It’s encrypted in your browser before it’s stored, so the server only ever holds ciphertext.
- Click Refresh. CostCompass reads your daily event and recording counts, prices them into money, and from there your running cost, forecast, and by-product split roll up — PostHog folded into the whole-stack number.
Frequently asked questions
- What kind of PostHog key does CostCompass need?
- A PostHog personal API key with two read scopes — query:read and session_recording:read — on the project you want to track. CostCompass uses it to run two read-only queries against your project — a daily count of ingested events, and a daily count of session recordings. CostCompass checks both scopes work the moment you connect, so a key missing one becomes a setup-time message rather than a half-empty dashboard on your first refresh. It works with both PostHog Cloud regions — US and EU — and figures out which one your key belongs to when you connect; one key covers the project's tracked products.
- Does CostCompass store my PostHog API key?
- Not in any form we can read. Your API key is encrypted in your browser with your vault password before it leaves your device, and what CostCompass keeps is only the resulting ciphertext — an opaque blob it can't decrypt, since your vault password never leaves your browser. When it's time to read your PostHog usage, the key is unsealed in your browser and forwarded to PostHog through a relay that holds it only for the length of that one call and is built not to log it. So that request does pass the key through our infrastructure, but the plaintext is never written to our database or our logs — what we store at rest is ciphertext, useless without your vault password.
- Which PostHog products does CostCompass track?
- Three — Product Analytics event ingestion (pageviews, autocaptured interactions, identify calls, and custom events), Session Replay recordings, and LLM analytics (PostHog's "AI Observability" — the generation and span events your LLM calls send, metered on their own separate allowance). Those are the parts of your PostHog bill it reads and prices. Feature Flags, Experiments, Surveys, and the Data Warehouse are deliberately left out — PostHog doesn't expose their usage through the query API CostCompass reads, so rather than guess at them it tracks the products it can measure accurately and tells you that's the scope.
- Why are some of my PostHog events charged more than others?
- Because PostHog prices an identified event higher than an anonymous one — up to 4x — and most products send a mix of both. The difference is person processing — an identified event creates and maintains a person profile, which means lookups and resource-intensive table JOINs, while an anonymous event is just a standalone record. So a logged-out pageview is cheap, but the same action from a signed-in user, tied to their profile, costs more. CostCompass mirrors that when it prices your counts — it charges identified events at the higher rate the way PostHog's own meter does — so the figure reflects your real mix instead of a flat per-event guess.
- Why did my PostHog bill suddenly spike?
- A spike usually traces to one of a handful of sources — autocapture sending more events than you actually use, an identify() or group() call firing on repeat instead of once a session, a jump in identified (profile-bearing) events, or Session Replay recording more sessions than you need. PostHog's own billable-usage dashboard breaks the month down by event, library, and product so you can see which one climbed. CostCompass works the other side of it — turning those counts into a running month-to-date cost with a per-day trend, so the spike reads as money the moment you refresh, while there's still month left to act on it.
- Can CostCompass cap or stop my PostHog spend?
- No — CostCompass reads your spend, it doesn't sit in front of PostHog's ingestion, so it can't block an event or enforce a limit. PostHog itself can — a billing limit per product stops ingestion once you cross it — but the tradeoff is that anything sent past the limit is dropped permanently, not queued or backfilled. That makes catching a spike early the better defense, and that's CostCompass's part — a running total and a per-day trend that make a climb visible while you still have room to decide, before a hard limit starts throwing data away.
- Does CostCompass work with self-hosted PostHog?
- No — it connects to PostHog Cloud, either the US or EU region. A self-hosted PostHog install doesn't generate a PostHog bill for a spend tool to track, so CostCompass reads usage from the Cloud query API and leaves self-hosted deployments out.
- Why use CostCompass instead of PostHog's own billing page?
- PostHog's billing page projects PostHog's own spend, for PostHog alone, in PostHog's console — useful, but it stops at PostHog, and you read it apart from everything else you pay for. It won't tell you how PostHog sits next to the rest of your bill, or where your whole stack lands this month. CostCompass prices the same usage feed and rolls PostHog up with Claude, OpenAI, your GPU rentals and hosting into one running cost and forecast — current the moment you click Refresh, instead of a per-tool total you go read in each provider's own console.
About the author
Joubert Berger builds CostCompass, a spend-intelligence dashboard that pulls usage from AI and compute providers into one month-to-date total, a forecast, and a per-provider breakdown. This guide reflects how CostCompass reads each provider's own usage API — see thesecurity model for how your keys are handled.
Stop reading PostHog spend in event counts
Connect PostHog once and turn its event and recording counts into a live running cost, a forecast, and a split by product — rolled up with every other provider, in one click.