Cloudflare Access pricing trap - how much are you really paying per user?

You've hit on a major hidden cost - the audit trail reconstruction. I once spent three days on an incident review pulling logs from six different microservices just to map one user's path, because our consolidated gateway's logs didn't capture the downstream app-specific authorization checks. The time spent building that timeline was more expensive than a year of the per-app seat fees we were trying to avoid.

The central problem is you're trading a defined, if expensive, security model for a bespoke one where the failure modes are unknown until you're in a breach scenario. That token scope mismatch is a classic example of a latent flaw that only surfaces during a compliance deep dive.

Wait, so it counts the same person separately for each app? That's wild. I was about to set this up for our team's admin panel and monitoring tools, thinking the cost would just be our 8 devs.

So if I have an app for Grafana and another for our staging env, and one dev uses both, that's two $7 seats? Even if they only used one once?

Yes, that is precisely how the multiplier functions. Your core team of ten is not ten billed users, it's ten users *times* the number of discrete Access applications they each authenticate to within the billing cycle. The billing granularity is at the user-application pair level, not the user identity level.

Your contractor example highlights the secondary issue, which is the lack of a prorated or usage-based cost for infrequent access. A contractor who authenticates once on the first day of the month to a single app occupies a full seat for that entire month, incurring the same $7 as your core member who uses the app daily. This model effectively penalizes application sprawl and sporadic access patterns, which are common in development and testing environments.

The dashboard's billing summary will only show you the final aggregated "active user" count, which is that multiplied figure. To forecast, you must manually analyze audit logs per application, as others noted. This discrepancy between the apparent simplicity of the per-user price and the actual per-user-per-app billing is the core of the trap.

Oh, totally feel that initial excitement turning into sticker shock. You nailed it with the multiplier effect.

The beta tester example is a huge one. Even if they just log in once to validate something, that's a full $7 seat for the month. We saw that with preview environments for designers - they'd hop in for ten minutes, then we'd get the bill.

For us, the bigger surprise was service accounts and CI/CD bots. They're just checking status but they count as "users" too. 😬 So that $70 for 10 people can quietly double before you even add your contractors.

The script check is smart, but it's also more work you're taking on to fix their opaque billing. You're now running your own compliance audit for a service you pay for.

Also, querying logs for seat counts is reactive. You find out after the fact. It doesn't stop the charge, it just tells you why you got it. You need to pair it with a process to deprovision or consolidate apps proactively, which is even more overhead.

Exactly, and that contractor's quick peek at the staging site is a perfect example of why calling this a "security product" feels a bit generous. You're billed for their access to a new "app" because their dashboard forced you to create a separate domain for staging, not because you created a new security boundary. The permission difference between a dashboard and a staging site is usually just a group membership, which should be a policy check, not a seat sale.

It's per-user-per-door pricing for a bunch of doors they built into the hallway.

Your hallway analogy is painfully accurate. The architectural choice to make each subdomain a distinct "application" for billing is what creates the door multiplier.

But the real trap is that this design then dictates your security model. Because you're financially pressured to consolidate onto a single domain to avoid the per-door fee, you end up building a monolithic gateway app. That means you're now responsible for implementing path-based authorization, session management, and audit logging for everything behind it, which are the very features you were buying from Cloudflare.

So you pay them to avoid building auth, but their pricing forces you to build a custom auth layer anyway. You just move the cost from your cloud bill to your engineering payroll, with added risk.

Oof, that's a brutal way to find out. The beta tester one really gets me - they log in once to confirm a fix and you're on the hook for a whole month's seat.

So just to make sure I understand, if one of your core team members needs to check *three* different things behind Access in a month, that's three separate $7 charges for that same person?

Your math is already wrong before you even finish the example. It's not 10 core team members at $70. It's 10 members *times* the number of apps they each touch. If they use three apps, that's 30 billed seats.

The trap is you're planning your costs based on headcount, but the bill is calculated on usage across their artificial application boundaries. You'll never hit your $70 estimate.

Precisely. You've identified the multiplier, but let's talk about that first line of defense, the "10 core team members" estimate. That's the anchor price they want you to calculate and feel good about. You're thinking in identities, but they're billing connections. The mental model is fundamentally wrong from the start.

Your contractor and beta tester examples are just the visible leaks. Wait until you start automating things. Every service account, CI/CD pipeline, or monitoring check that hits a protected endpoint is a "user" for the month. That staging site your deployment pipeline pings once? That's another $7.

So your simple $70 becomes $70 for the core team touching one app, plus $35 for the contractors, plus $7 for each beta tester, plus $7 for each service account, multiplied by every other app they might need to touch. You weren't buying a security gateway, you were buying a metered toll road for your own hallway.

Yep, that mental model shift from identities to connections is the whole trap. They sell it as a per-user cost, but that's not what they're counting.

The automation tax hit us hard. Our GitLab CI pipelines needed to hit a few internal endpoints for status checks. Suddenly, each pipeline runner was a monthly "user" for every app it touched, even though it was the same script. It felt like paying a subscription fee for a cron job.

Yeah, the dashboard's "Active Users" count is the high-level view and doesn't show the per-app breakdown that drives the bill. You're right to be wary.

You can piece it together by going to the specific Access Application page, then the "Users" tab. It'll show you who's accessed that individual app. But to get the full multiplier picture, you have to check every single app, one by one, and then collate it yourself. There's no consolidated report that says "Here are your 10 people and the 3 apps each touched."

So in practice, you either do that manual, time-consuming check across all apps, or you wait for the bill and then use the audit logs to reverse-engineer the charges. It's pretty frustrating.

Right, so the dashboard shows me the numbers but not the math. That's the part that's so confusing.

So the "Application Traffic" report is basically useless for predicting my bill? I'm just supposed to trust that the final charge will make sense?

And about the billing snapshot, that means if we have a big onboarding day where everyone checks all our tools, we get punished harder than if they spaced it out over weeks? That feels backwards.

Yes, the traffic report is useless. It measures something different from what they bill for.

>if we have a big onboarding day... we get punished harder
Exactly. Their system incentivizes bad security hygiene by encouraging you to stagger access to avoid charges. Any model that does that is broken.

The snapshot approach also makes budgeting impossible. A single spike in legitimate activity can blow your forecast. You can't manage what you can't predict.

That's not the half of it. You're still thinking like a user, not like a billable unit. The "10 core team members" line is the setup. Your contractors and beta testers are the predictable first overage.

Wait until your first security audit. The auditor needs read-only access to five different systems for one week. That's five monthly seats, for one person, for a one-time event. Their pricing model turns compliance into a recurring capital expense.

Did you factor that into your simple $70?