The MAU (Monthly Active User) billing model is the most misunderstood and most complained-about aspect of LaunchDarkly pricing. It's the most common source of cost surprises. This page explains exactly what an MAU is, why it matters, and how to control your costs.
An MAU is any unique user who receives at least one feature flag evaluation in a calendar month.
LaunchDarkly identifies users by a "user key" — typically an account ID, email, or generated UUID. Every time your code calls variation() with a user context, that user is counted as an MAU for the month. It doesn't matter how many flags they hit or how many times they visit — it's once per unique user per month.
The most common LaunchDarkly cost surprise: A team evaluating LaunchDarkly for a team of 10 engineers assumes the cost is 10 × $20 = $200/month. Then they deploy to production and discover their app has 80,000 monthly users — all of whom are now MAUs. The MAU component often exceeds the seat cost for consumer-facing apps.
| Your situation | Team seats | End users (MAUs) | Pro seat cost | MAU impact |
|---|---|---|---|---|
| 3 devs, internal tool | 3 | ~50 internal users | $60/mo | Minimal — well within limits |
| 5 devs, early SaaS (2k users) | 5 | 2,000 | $100/mo | Low — monitor as you grow |
| 10 devs, growing SaaS (20k users) | 10 | 20,000 | $200/mo | Significant — contact sales for rates |
| 15 devs, mid-market SaaS (100k users) | 15 | 100,000 | $300/mo | Dominant cost — negotiate MAU caps |
| 20 devs, B2C app (500k users) | 20 | 500,000 | $400/mo | Very large — evaluate ConfigCat/DevCycle |
Server-side evaluation lets you control exactly which users are identified. You can choose to only pass user keys for paying users, logged-in users, or specific segments — rather than all visitors.
Each unique anonymous key counts as an MAU. If you generate new anonymous UUIDs per session rather than persisting them, you'll accumulate MAUs faster. Persist anonymous keys where possible, or avoid anonymous evaluation for flags that don't need it.
Only expose users to flag evaluations when it's meaningful. If a flag is for a beta feature only 1% of users will access, don't evaluate it for 100% of users.
The Relay Proxy centralises flag evaluation and can reduce MAU attribution complexity in server-side contexts. It's worth deploying at medium-to-large scale.
LaunchDarkly's dashboard shows MAU trends. Review which flags are generating the most MAU evaluations and consider whether all of them are necessary.
If the MAU model is the problem, these alternatives use different billing approaches:
MAU overage pricing is not publicly listed by LaunchDarkly. Estimates based on public community reports. Contact sales for exact MAU pricing at your volume.