PostHog Pricing in 2026: What You Actually Pay

As of July 2026, PostHog has no monthly subscription and no seat pricing. It is free to start, needs no credit card, and each of its products meters independently once you cross a generous free allowance. That design is why the same tool shows up in one Reddit thread as "basically free" and in the next as a "$60k/month" bill. Both are true. The difference is almost never the plan; it is how many events you send, whether they are identified, and whether you set a billing limit.

PostHog is a usage-based product analytics platform that bundles analytics, session replay, feature flags, experiments, surveys, error tracking, and a data warehouse under one $0 base. This is the arithmetic the pricing page and the third-party summaries leave out: the per-product free tiers, the identified-event multiplier, and three real 30-day bills you can map onto your own traffic.

How PostHog pricing works in 2026

There are two plans: a Free plan and a Pay-as-you-go plan that also starts at $0/month. Neither has a fixed fee. You are billed per product, per unit, and only after that product's free tier is used up. From PostHog's own pricing page (July 2026, re-verified against it on October 5, 2026 with every free allowance and every analytics tier rate below unchanged), the monthly free allowances are:

Two things fall out of this table that single-number teardowns miss.

First, the free tiers stack. Because each product has its own allowance, a small app can run analytics, replay, flags, surveys, and error tracking all at once and still pay nothing. Tools that meter on monthly tracked users (MTUs), like Mixpanel or Amplitude, bill against one shared meter, so the same activity lands on a single growing line. PostHog's split meters are genuinely friendlier at the bottom.

Second, the price is marginal and tiered. Product analytics does not cost a flat $0.00005 forever. The rate steps down as volume rises:

So the second million events costs $50, but the fifteenth million costs $34.30, and beyond 250M events you are paying $9 per million. Effective cost per event drops the more you send.

The identified-event trap that quietly quadruples your bill

Here is the single biggest lever, and it is buried in the docs rather than the pricing page. PostHog charges more for identified events than anonymous ones. From PostHog's anonymous vs identified events documentation (2026): "Anonymous events can be up to 4x cheaper than identified ones."

An event becomes identified the moment your code calls identify(), alias(), group(), or setPersonProperties(). After that, PostHog builds a person profile and every subsequent event for that user is billed at the identified rate. Call identify() on every pageview and your $0.00005 events can quietly bill at up to four times that.

The fix is a one-line config, not a plan change. PostHog's recommended default is person_profiles: 'identified_only', which captures anonymous events by default and only creates a person profile when you explicitly identify someone (a signup, a login). In backend SDKs, setting $process_person_profile: false keeps high-volume server events anonymous. Most teams do not need a person profile on a marketing pageview; they need it on the ten events after login.

The 4x is a ceiling, not a flat multiplier, and PostHog publishes the proof. Identified events are billed as a separate line item on their own tiered rate card, listed on the pricing page as the Identified events add-on to product analytics. PostHog's docs are explicit that the two are not stacked: "We're not charging you for both. The person profiles line item you see on your invoice is a number of identified events captured. The events line item is the total number of anonymous events captured." So an identified event is billed at the add-on rate instead of the anonymous rate, and comparing the two tables shows the premium collapsing as volume rises:

The 3.96x on the second million is where PostHog's "up to 4x" comes from, and it is the maximum. By 15M events the premium is 2x, and above 50M identified events are actually cheaper than anonymous ones. Identifying everything is an expensive mistake on a small or mid-sized app and close to a non-issue on a very large one.

Math check preview: on a 5M-event month, the analytics line is $152.90 if those events are anonymous and $407.10 if every one is identified, a 2.7x difference decided by one SDK flag. The 4x ceiling applies to the second million only; past that it shrinks, and above 50M events it inverts.

Three real 30-day PostHog bills

Numbers below use the July 2026 rates above, anonymous events unless noted, and add up the products a typical team actually turns on.

Bill 1: the side project, $0

800,000 analytics events, 3,000 web session replays, 300,000 feature-flag requests, and 40,000 error-tracking exceptions. Every figure sits under its free tier (1M / 5K / 1M / 100K).

Total: $0.00/month. This is the "too good to be true" thread on r/nextjs. It is real, as long as you stay under the allowances.

Bill 2: the growing B2B SaaS, about $370

5M analytics events (anonymous), 12,000 web replays, 3M feature-flag requests, 200,000 error-tracking exceptions.

Two lessons here. Feature flags are the surprise line: the first paid million of flag requests costs $100, more than the first three million analytics events. If you evaluate flags locally in your backend instead of calling PostHog on every request, that line collapses. And if those 5M events were all identified, the analytics line alone climbs from $152.90 to $407.10 on the add-on rate card, pushing the total to $624.10. The config flag, not the traffic, decides which SaaS you are.

Bill 3: the high-volume consumer app, and the $60k horror story

Take 60M analytics events a month, kept anonymous with autocapture tuned, plus 50,000 web replays.

Now the cautionary tale. A product manager on r/ProductManagement reported that at 300M+ events "PostHog's cloud option, the cost went up to ~60k$ per month." That is not a different price list, and it is worth being precise about what does and does not explain it. At 300M events the published tiers put anonymous analytics at $5,318.40 and identified analytics at $3,699.10, so at that volume identifying every event does not inflate the analytics line at all, it is about 30 percent cheaper. The identified-event premium cannot produce a five-figure bill. What can is raw volume across many products at once plus autocapture firing many events per interaction with no filtering. Autocapture is convenient and it is also why the r/reactnative thread describes an "ideal spend ~$50/month" that ballooned until the author "tried disabling autocapture." Volume you never chose to send is still volume you pay for.

How to cap PostHog so you never get a surprise bill

The answer to the horror story is a feature PostHog ships and almost nobody enables: per-product billing limits. From the pricing page, "You can set billing limits for each product so you never get an unexpected bill." Set a dollar cap on analytics, another on replay, and when you hit it PostHog stops ingesting that product's data for the rest of the month rather than billing past your number. It is a hard ceiling, per product, and it turns an open-ended usage bill into a budget you control.

The other levers, in order of impact:

• Keep events anonymous by default (identified_only); identify only after signup. Up to 4x.
• Tune autocapture or switch to explicit capture() calls for the events you actually analyze. Cuts raw volume.
• Evaluate feature flags locally in the backend to avoid a request per check.
• Sample high-frequency events, and set billing limits as the backstop.

One correction for anyone reading older guides: teardowns from 2024 and early 2025 still cite a "$65/month basic plan for 5,000 sessions." That plan is gone. In 2026 PostHog is pure pay-as-you-go on a $0 base; the paid tiers you will see, Boost at $250/mo, Scale at $750/mo and Enterprise at $2,000/mo, buy platform features rather than usage. PostHog's own package table puts unlimited projects, white labeling, a HIPAA BAA and SSO enforcement in Boost; priority support and SAML in Scale; and RBAC, dedicated support and training in Enterprise. Your usage is billed the same whether or not you add any of them.

Correction, October 5, 2026. This page previously put a fully identified 5M-event month at "up to roughly $610" and a total of "past $800", and it explained the $60k report partly as "every event identified (up to 4x)". PostHog publishes identified events as a separately tiered add-on, and on those rates 5M identified events cost $407.10 (total $624.10) while at 300M events identified analytics is cheaper than anonymous, so the 4x is a ceiling on the second million rather than a flat multiplier and it does not explain a high-volume bill. The page also previously listed RBAC among what Boost and Scale buy; PostHog's package table places RBAC in Enterprise at $2,000/mo. Every free allowance and every analytics, replay, flag and error-tracking rate quoted here was re-verified against posthog.com/pricing and remains unchanged.

Is PostHog cheaper than the alternatives?

Honestly, it depends on shape, not logos. For an early product juggling analytics, replay, and flags, the stacked free tiers make PostHog hard to beat, and if you only want privacy-friendly web stats, a flat tool like Plausible or free GA4 may be simpler. At high, mostly-identified volume, an MTU-priced competitor can undercut usage pricing, which is exactly why the r/analytics consensus is "PostHog is great for startups since it's cheaper" with the caveat that it scales in cost with usage. PostHog also overlaps tools you may already pay for: its error tracking competes with a dedicated monitor, so if you are pricing that separately it is worth reading our Sentry pricing teardown alongside this one, and its usage-metered model rhymes with other per-unit infra like Upstash.

Math check: PostHog's bill is set by volume across independently metered products, not by a plan. The identified-event premium is a second rate card that runs 3.96x the anonymous rate on the second million and falls below 1x above 50M events, so it is the lever that matters at small scale and not the one that matters at large scale. Set a per-product billing limit, keep events anonymous by default while you are small, and tune autocapture once you are not.