# PostHog Pricing: Estimate Each Product Separately Canonical URL: https://www.martechdevs.com/blog/posthog-pricing By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo) Data Engineer and Co-founder, martechdevs Published: 2025-11-17 Last updated: 2026-09-18 PostHog charges by product usage, so estimate analytics events, recordings and feature flag requests separately. Start with each product's monthly free allowance, apply its volume tiers, and then add relevant add-ons. For analytics, distinguish anonymous from identified events. A single headline event rate or monthly active-user count is not enough to predict the bill. PostHog can be inexpensive for a focused implementation. It can also collect more than a team expected when automatic interactions, repeated flag evaluations and broad replay capture are enabled together. The useful budgeting question is not “How many users do we have?” It is “What does each user journey cause each product to collect or evaluate?” This guide covers the pricing structure visible on 18 September 2026 and a reproducible estimate for a limited web workload. All prices are USD before tax. Your billing page and agreement should confirm the rates applicable to your organization. [PostHog pricing](https://posthog.com/pricing). ## What do the main products charge for? Treat each product as a separate line in the estimate. Three common lines are analytics events, replay recordings and flag requests. A recording is not an event, and a flag request is not a monthly active user. The current analytics calculator lists one million events free each month, then USD0.0000500 per event from one to two million and USD0.0000343 from two to 15 million. Lower marginal rates apply at higher volumes. These headline rates must be read alongside the anonymous-versus-identified distinction below. [Product Analytics pricing](https://posthog.com/product-analytics/pricing). For web replay, the first 5,000 recordings are free monthly. The next tier, from 5,000 to 15,000, is USD0.0050 per recording, followed by USD0.0035 from 15,000 to 50,000. Native mobile recordings are billed separately with a 2,500-recording free allowance and different rates. [Session Replay pricing](https://posthog.com/session-replay/pricing). Feature flags and experiments share request-based pricing. The first million requests are free monthly; the one-to-two-million tier is USD0.000100 per request and the two-to-ten-million tier is USD0.000045. [Feature Flags pricing](https://posthog.com/feature-flags/pricing). Those are marginal tiers. Crossing a threshold does not mean applying the newest rate to every unit in the month. Calculate the usage inside each tier, multiply by its rate and add the results. A [product analytics implementation](https://www.martechdevs.com/product-analytics) should include this usage model. Collection settings affect both what the team can learn and what it pays to retain that evidence. ## Why does the anonymous-versus-identified distinction matter? PostHog's current documentation distinguishes anonymous events from events associated with a person profile. The first million events are free across both types together. Identified events have different processing and pricing implications, so the anonymous headline rate should not be treated as a complete price for a logged-in application. [Anonymous and identified events](https://posthog.com/docs/data/anonymous-vs-identified-events). For a mixed workload, record total events and the identified share. Then use your organization's pricing view or calculator for that mix. Do not count one million free anonymous events plus another million free identified events. The distinction is about the analytics model, not simply whether the payload contains an email address. Removing an email property from an already identified user's event does not necessarily turn it into an anonymous event. Nor should you force important logged-in journeys into an anonymous model solely to lower the bill. If the decision requires person properties or account analysis, removing the necessary context can make the data less useful than the money saved. For an initial forecast, split the website and application journeys conceptually. A public content visit may need aggregate acquisition analysis. An authenticated workspace action may need stable person and account context. Validate the actual configuration and measured usage rather than assuming those labels determine billing automatically. ## Build a usage model from journeys Start with representative journeys and count the operations they produce. Include a quiet visit, a typical active session and a heavy workflow such as editing or importing data. For analytics, separate purposeful business events from automatic interactions. A form submission that generates a click, a submit event, a success event and a pageview produces several records. Whether all are useful depends on the questions being answered. For replay, estimate sessions eligible for recording after your recording rules. One person can have many sessions. A pageview count is not a recording count. For flags, measure evaluation requests across initialization, identity changes, group changes and explicit reloads. The official estimation guide explains why front-end requests and server evaluation patterns need separate treatment. [Estimating usage and costs](https://posthog.com/docs/billing/estimating-usage-costs). Then project the monthly workload. Use a representative period including weekdays and weekends, and separately model launches, campaigns or unusually heavy customers. A one-day sample from a release incident should not become the baseline for normal usage. For each estimate, keep the observed unit, sample period, expansion assumption and owner. This makes a later bill explainable: the team can determine whether the rate changed, the audience grew or the application began producing more work per journey. ## A worked monthly estimate for a web workload Consider an illustrative public website using only anonymous analytics events, web replay and remote feature flag requests. It has no group analytics, mobile replay, warehouse, pipelines, AI products or other paid add-ons in this example. Assume the measured monthly volumes are: - 1,500,000 anonymous analytics events. - 12,000 billable web recordings after recording rules. - 1,200,000 billable feature flag requests. Using the public tiers above, the analytics estimate is 500,000 paid events multiplied by USD0.0000500, or **USD25**. The replay estimate is 7,000 paid recordings multiplied by USD0.0050, or **USD35**. The flag estimate is 200,000 paid requests multiplied by USD0.000100, or **USD20**. The combined estimate is **USD80 per month before tax** for those three lines only. This is arithmetic using a synthetic workload, not a quoted price for your company. In particular, it must not be reused unchanged for an identified-user application. ### What happens when usage grows unevenly? Now assume analytics rises to 2.4 million events, web recordings rise to 24,000 and flag requests rise to 2.4 million. Different changes in the product could produce those different growth rates. Analytics becomes USD50 for the first million paid events, plus USD13.72 for the next 400,000, totaling **USD63.72**. Web replay becomes USD50 for the 10,000 recordings in its first paid tier, plus USD31.50 for the next 9,000, totaling **USD81.50**. Feature flags become USD100 for the first million paid requests, plus USD18 for the next 400,000, totaling **USD118**. The combined estimate is now **USD263.22** before tax and excluded products. A forecast that simply doubled USD80 would miss both the different usage growth and the interaction with free allowances. Build low, expected and high cases using actual product behavior. The point is to understand which usage line moves the budget, not to invent a single impressive-looking precision figure. ## Which add-ons and details change the estimate? ### Group analytics B2B teams should inspect group analytics separately. PostHog documents it as a paid add-on whose usage covers all identified events after it is enabled, not only events carrying group properties. [Group analytics billing](https://posthog.com/docs/product-analytics/group-analytics). That means “we send only 10,000 workspace-tagged events” is not enough to estimate the add-on. Establish the identified-event workload first, then confirm the applicable rate and allowance in the billing view. Keep the commercial question connected to the analytical one. If account activation is an essential metric, the add-on may be justified. If the team only needs a list of users with a common attribute, clarify whether it is asking for account aggregation or merely a segment. ### Retention and additional products Do not assume every product retains data for the same period. The pricing pages distinguish analytics retention from recording retention, and paid add-ons can alter the replay retention available. Verify the period required for your investigation and reporting process before treating the free tier as sufficient. Inventory any warehouse ingestion, destination exports, surveys, error tracking, logs or AI-related capabilities you intend to use. The [overall pricing page](https://posthog.com/pricing) lists separate units across products. Keep excluded products visible in the budget even when their initial expected charge is zero. An estimate should say “not enabled” or “included at this measured volume,” rather than silently omitting a product that may later appear on the invoice. ### Server-side flag evaluation Server usage depends on architecture. A request for every operation, multiple application instances and local-evaluation polling produce different patterns. Do not multiply pageviews by a frontend request count and assume that covers the backend. Local evaluation can reduce remote evaluations, but definition polling still has billing behavior. The current guide distinguishes polling responses and SDK capabilities. Review the supported SDK version and number of running instances before claiming local evaluation makes the flag line free. [PostHog usage estimation](https://posthog.com/docs/billing/estimating-usage-costs). ## What happens when a billing limit is reached? A billing limit protects spend by stopping ingestion and processing for the affected product. PostHog explicitly warns that additional data beyond the limit is lost. Its pricing FAQ also describes a quota-limited default response for feature flags. [Billing limits and alerts](https://posthog.com/docs/billing/limits-alerts), [pricing FAQ](https://posthog.com/pricing). Treat that as a product behavior to plan for, not just a finance setting. A hard analytics limit can create a hole in the period being compared. A flag fallback can affect what customers experience. Assign an owner to each limit and define what they should do before it is reached. The billing-limit documentation describes alerts at 80% and 100%; make sure the relevant owner can see and act on them. For analytics, write down how an incomplete collection period will be marked in reporting. For feature delivery, test the application's fallback behavior in a controlled environment. Do not learn what the default variation does during a traffic spike. ![Measure each product unit, apply tiers and add-ons, model peaks and plan consequences of limits.](https://www.martechdevs.com/assets/blog/posthog-pricing.svg) ## Reduce waste without removing the evidence you need Investigate the largest usage drivers before disabling broad categories. Repeated low-value interactions, accidental duplicate initialization and unnecessary reloads are better optimization targets than the business outcomes used to judge activation. Review events per completed journey, recordings per eligible session and flag requests per application operation. Those ratios help distinguish healthy growth from an implementation change. For example, if visits remain stable while analytics events per visit double after a release, inspect the added capture path. If replay grows while eligible sessions remain stable, review recording configuration. If flag requests grow with server instance count rather than customers, examine polling and evaluation design. Keep a small set of acceptance journeys after every change. Removing a noisy interaction should not accidentally remove the only event that identifies a failed onboarding step. The [PostHog implementation guide](https://www.martechdevs.com/blog/posthog-implementation-mistakes) covers that diagnostic work. Compare tools only after normalizing the workload. Our [product analytics pricing guide](https://www.martechdevs.com/blog/product-analytics-pricing) explains why event-based and user-based quotes cannot be compared using their smallest advertised numbers. The [PostHog versus Mixpanel comparison](https://www.martechdevs.com/blog/posthog-vs-mixpanel) adds the workflow tradeoffs. Before approving the estimate: ## Checklist - [ ] Anonymous and identified usage are measured separately without doubling the free allowance. - [ ] Web and mobile recordings use their own billing units and allowances. - [ ] Flag request estimates include browser and server behavior. - [ ] Marginal tiers are applied to the correct portion of usage. - [ ] Group analytics and every other enabled product appear in the budget. - [ ] Limits have owners, alerts and tested behavior for critical workflows. - [ ] The expected and peak cases identify which assumption drives the difference. A useful budget is one the product team can influence. It connects each cost to a collection or evaluation decision, so reducing waste also makes the implementation easier to understand. ## Frequently asked questions ### Is PostHog free? Each product has a monthly free allowance, and a limited workload can remain within it. Free usage is still subject to product limits and retention rules. Check the specific capabilities and volumes you need rather than treating the whole platform as unlimited. ### Does the USD0.0000500 event rate cover identified users? Do not use that headline rate as a complete estimate for identified traffic. PostHog's documentation distinguishes anonymous events and person-profile processing, with different pricing implications. Confirm your event mix and applicable charges in the organization's pricing view. ### Is a replay recording the same as a user? No. One user can generate several sessions and recordings during a month. Estimate the number of sessions that qualify under your recording rules, and keep native mobile recordings separate from web recordings. ### Will increasing a billing limit recover dropped events? You should not assume so. PostHog's billing-limit documentation says additional data beyond the limit is lost. Monitor before the limit is reached and mark affected reporting periods if collection is interrupted. ### How much should we budget for implementation? That depends on the journeys, identity rules, account model, consent requirements and existing data quality. Estimate that work separately from software usage. A low subscription bill does not mean the team can skip the effort required to make its reports trustworthy. ## Sources 1. [PostHog: Pricing and FAQ](https://posthog.com/pricing). Accessed 18 September 2026. 2. [PostHog: Product Analytics pricing](https://posthog.com/product-analytics/pricing). Accessed 18 September 2026. 3. [PostHog: Session Replay pricing](https://posthog.com/session-replay/pricing). Accessed 18 September 2026. 4. [PostHog: Feature Flags pricing](https://posthog.com/feature-flags/pricing). Accessed 18 September 2026. 5. [PostHog: Anonymous versus identified events](https://posthog.com/docs/data/anonymous-vs-identified-events). Accessed 18 September 2026. 6. [PostHog: Estimating usage and costs](https://posthog.com/docs/billing/estimating-usage-costs). Accessed 18 September 2026. 7. [PostHog: Group analytics](https://posthog.com/docs/product-analytics/group-analytics). Accessed 18 September 2026. 8. [PostHog: Billing limits and alerts](https://posthog.com/docs/billing/limits-alerts). Accessed 18 September 2026.