You've identified the initial multiplier, but you're still thinking about individual users. Wait until you realize that each of those separate applications likely counts as a separate billed "seat" per person.
If your 10 core members need the staging site, the database panel, and the wiki, that's not 10 users at $7. It's 30 active user-application pairs. Your bill is already triple what you budgeted for, and you haven't even added the contractors yet. The $70 baseline is a fantasy for any real-world setup.
Show me the data
Ugh, yes, your contractor and beta tester breakdown is the perfect example of where the "simple" pricing starts to unravel. Even with people who only need one app, you're still adding a full seat for each group.
It also makes forecasting a nightmare. If one of those contractors needs to check something in the wiki just once, that's another user-app pair added to your bill that month. Your $70 baseline can get shaky really fast.
null
Totally feel your pain here. That contractor and beta tester breakdown is exactly where the "simple" pricing starts to unravel. Even with people who only need one app, you're still adding a full seat for each group.
It also makes forecasting a nightmare. If one of those contractors needs to check something in the wiki just once, that's another user-app pair added to your bill that month. Your $70 baseline can get shaky really fast.
Happy customers, happy life.
Exactly. The forecasting nightmare gets worse when contractors work with multiple clients using Access. Each client's separate apps count as new user-app pairs for the same contractor.
So your $70 baseline isn't just shaky, it's completely unknowable. How are you supposed to track if a contractor logged into one client's staging and another client's wiki?
You're focused on your contractors and beta testers as separate groups, but you're missing the real structural problem. This isn't an edge case with part-time users. It's how the product is architected.
Your 10 core team members are the trap. If each one logs into your staging site, database panel, *and* wiki, that's not 10 users at $70. That's 30 user-app pairs. You're already paying $210 before a single contractor logs in. The bill you're worried about is built on a foundation you've already mispriced.
Trust but verify.
That's the exact scenario that got me. The initial math with the core team seems fine, but then those other groups push you into the next billing tier. It's not just 5 more seats, it's like adding another whole block of users.
I'm curious, when you added those contractors, did you see a clear jump in your billed user count right away in the dashboard, or was it only obvious when the invoice hit?
PipelinePadawan
The dashboard shows active user counts, but I had to cross-reference our actual billing history to see the real impact. It only became clear when we compared months.
Our jump happened because a contractor accessed two different tools, which counted as two separate "seats" for the same person. Does your dashboard break down the count per application, or is it just a total number?
Oh, the dashboard is a big part of the confusion! It shows a total "Active Users" number, which is that user-app pair count they charge for. You have to dig into the "Application Traffic" report to see the per-app breakdown, and even then, it doesn't directly map to the billed number. You're left guessing which combination of logins triggered the seat.
Our jump came from a designer who logged into both our prototype feedback tool and our design system hub. One person, two "seats" instantly. I only pieced it together by matching timestamps in the audit logs with the billing snapshot.
Anyone else find a reliable way to predict the billed count from the dashboard, or do you all just wait for the invoice like we do now?
You've nailed the initial shock perfectly. That multiplier effect with multiple applications is exactly what makes forecasting so difficult. I've seen similar setups where even a small, seemingly logical team expansion - like adding a few QA testers to just the staging site - can trigger an unexpected jump in the billed count.
What often compounds this is that the Access pricing model can clash with how teams are structured. Your 10 core members needing three apps each is already 30 "seats" as others have pointed out. But then when you add contractors for a single tool, you're not just adding their seat, you're potentially pushing your core team's cost into a higher volume tier depending on how Cloudflare structures those brackets. It's rarely a simple linear addition.
Have you looked at whether grouping applications under a single domain with path-based rules (like `tools.yourcompany.com/staging`, `tools.yourcompany.com/wiki`) would still count as separate "applications" in their eyes? I've heard mixed results on that approach.
Stay connected
Ah, the classic "Active Users" vs "what you'll actually pay" bait and switch. You found the dashboard misleading too?
>Does your dashboard break down the count per application
It does, but not in a way that helps. The Application Traffic report shows logins per app, but it doesn't aggregate them back to the user-app pair count they invoice on. You're left staring at two separate, equally unhelpful numbers. One tells you traffic, the other tells you a total, and neither maps to the line item on your bill.
The real fun starts when you realize the billing snapshot isn't even a daily roll-up. It's a point-in-time count, so a user hitting three apps in the same hour costs the same as one hitting them across three months. Good luck forecasting that.
cg
Oh, you found the "seat multiplier." Classic. That $70 for your 10 core people is a fantasy. They're not 10 users, they're 10 potential app-accessors. Wait till you onboard that new dev and they need three tools on day one - instant triple charge for one human.
You think the contractor line item is bad? The real trap is your own team's routine access. Every app they touch in a month is another line on an invoice you never see coming.
Ever tried explaining that bill to your CFO? It's a fun chat. "No, the $7 per user is actually per hat they wear this month."
Deploy with love
Your breakdown of the core team plus contractors plus beta testers is the textbook case. It's the application-based counting that causes the leap, not just the headcount.
You're right to zero in on the definition of "active user." In their model, it's effectively a unique authentication event per user per application per month. So your 10 core members accessing three apps are 30 billed units, not 10. That's the foundational multiplier everyone misses.
The real forecasting challenge comes when those beta testers log in. Even if it's sporadic, each one is another unique user-app pair added to that month's count, pushing you closer to the next pricing tier. The invoice never reflects simple headcount; it's a tally of all those permission grants.
connected
Exactly. This is why forecasting is impossible without internal logs. Their "unique authentication event per user per application per month" definition means your peak concurrent access dictates the cost, not your average.
We built a sidecar script that pulls Cloudflare audit logs daily to calculate the true user-app matrix. Last month, our dashboard showed 42 "Active Users." Our script counted 127 unique user-app pairs because of one-off accesses. The invoice was for 127 seats.
If you're not reconciling their audit logs against the billing API, you're flying blind. The pricing model essentially charges for permission matrix sprawl.
—Alex
That multiplier effect you described is exactly why our forecast was off. We mapped the audit logs and found our "10 person" team had 58 active user-app pairs last month. The $7 per seat became $40 per actual human.
Is there a lag between the audit log data and the billing snapshot? We're seeing pairs that appear in our logs but don't always show up in the billed count.
You're just scratching the surface of the multiplier problem. That $70/month for your core team is pure fantasy. Each of those 10 people is a vector for three separate charges the moment they touch a different internal tool. The contractors and beta testers you mentioned are just the visible line items.
The real cost driver is the silent, routine access your engineers already perform. Every staging site login, every click on the admin panel, every wiki check - it's all additive. You don't have 10 users and 5 contractors. You have a dynamic permission matrix where each cell costs $7. You need to audit your actual user-app pair logins, not your headcount.