Auth0 Pricing and MAUs: Build Your Own Cost Estimate

Your bill depends on this definition, so read it before anything else. Typically an MAU is a distinct user who authenticated or was issued a token during the billing month. The details vary:

• Does a user who only refreshes a session count, or only one who logs in?
• Are machine-to-machine tokens and service accounts counted separately?
• Do free and paid users count the same?
• Are users in a test tenant counted?
• Is there a difference between B2C users and B2B organization members?

Ask each vendor to state these answers in writing. A definition that counts silent token refreshes can produce a very different number from your own analytics.

Collect these numbers before opening any pricing page:

1. Current MAUs, measured the way the vendor defines them, not by registered accounts.
2. Monthly growth rate, using the last three to six months as a guide.
3. Seasonality: does usage spike around launches or billing cycles?
4. User mix: free versus paid, consumer versus business, and how many are enterprise customers who will ask for single sign-on.
5. Features required: multi-factor authentication, social login, custom domains, organizations, role-based access and log retention.
6. Revenue per user: average monthly revenue per active user, including free users at zero.

Missing inputs are the main reason estimates go wrong. If you don't know your true MAUs yet, instrument logins for a month first.

Build a simple twelve-month table with one row per month. Start with today's MAU and multiply by one plus your growth rate each month.

Say you have 8,000 MAUs growing 10% a month. After twelve months that becomes roughly 25,000. Now lay the vendor's current tiers over your curve and mark each month where you cross a threshold. Two things stand out: the month your plan changes tiers, and any feature you need that exists only above a certain tier.

Threshold jumps matter more than the per-user rate. If a required feature such as enterprise single sign-on sits only in a higher plan, your cost can step up sharply the day your first large customer asks for it, even with few users. Model that scenario explicitly.

Convert the estimate into ratios you can compare across vendors and time:

• Cost per MAU per month at each stage of your projection.
• Authentication cost as a share of revenue, using your revenue per user. A free-tier consumer product with little revenue per user feels this far more than a B2B product with high contract values.
• Cost of the next tier relative to the users it adds.

Say authentication costs you $1,500 a month and your monthly revenue is $60,000. That's a small share and probably not worth engineering time to reduce. Now say the same bill sits against $6,000 of revenue: that deserves scrutiny. Revisit the numbers quarterly, and set an alert when MAUs approach the next tier.

You have several levers before you consider rebuilding anything:

• Redefine or reduce what counts as active, for example by shortening sessions so users don't generate extra authentications, if the vendor's definition allows it.
• Compare vendors on your own projection. Clerk is one alternative many teams evaluate, and the three-way comparison covers the criteria.
• Negotiate annual terms once your usage is predictable.
• Consider an open-source or self-hosted option, but count the engineering and security work, since authentication is a poor place to save money by cutting corners.

Switching has its own cost. Plan how to export users and password hashes, keep sessions alive during the move and support both systems for a while. If you're coming from another provider, see the guide to migrating from another hosted login service, and if you serve business customers, review the multi-tenant authentication architecture before choosing.