Just got the invoice notification for our JumpCloud instance. The per-user price increase is substantial, and the new "Platform" add-on fee for features that were previously bundled feels like a classic repackaging maneuver. This isn't a minor adjustment; it's a material change to the TCO for directory-as-a-service, especially for teams scaling beyond a few dozen users.
For those doing FinOps, this requires an immediate re-evaluation. The "set it and forget it" SaaS model just bit back. Here’s my action plan, which you might find useful:
* **Baseline the new annual commitment:** Calculate the net effective increase for your exact user count and required modules. Don't just look at the per-user list price; model the total bill.
* **Audit user lifecycle hygiene:** This is now a direct cost center. I'm scripting a cleanup of inactive accounts and service accounts that might be incorrectly tagged as users. Example filter for our internal reporting:
```sql
-- Pseudo-SQL for our internal CMDB
SELECT user_id, last_login, department
FROM directory_sync_log
WHERE last_login < NOW() - INTERVAL '90 days'
AND department NOT IN ('Service Accounts', 'External');
```
* **Re-run the build vs. buy analysis:** At the new price point, the operational overhead of a self-managed open-source stack (e.g., FreeIPA, Authelia, or even a small dedicated AD instance with secure federation) has a different break-even point. The calculus has shifted.
* **Evaluate the true necessity of the new "Platform" tier:** They've moved RADIUS and some advanced MDM policies behind this paywall. We need to verify if our usage of these features justifies the cost or if we can implement a more targeted, cheaper solution for the specific use case (e.g., a dedicated NAC for RADIUS).
The strategic question this forces: Is JumpCloud still our unified cloud directory, or has it become an expensive SSO/MDM provider that we supplement with other tools? For cost-optimized clusters, this pricing shift could push more workload-specific auth back into the Kubernetes layer (e.g., OIDC service accounts, shorter-lived tokens) to reduce dependency on the central, now more expensive, user directory.
What’s your revised per-user/month figure, and what alternative stacks are you re-evaluating to offset this? I’m particularly interested in real data on managing developer tooling (like GitHub SSO, CI/CD access) without a full-blown, all-features directory service.
—emma
FinOps first, hype last
That SQL snippet is a great example of the immediate hygiene work needed. I've been running similar queries against our Okta logs, and you'd be surprised how many "users" are actually dormant integrations or test accounts from old projects.
Your point about modeling the total bill is crucial. We did that and found the platform fee pushed our break-even point for building a custom SCIM connector way earlier than before. It's turning a managed service into a build vs. buy analysis again. Has your team started looking at alternative auth providers, or are you trying to absorb the cost by stripping features back?
Connecting the dots.
Your SQL filter is a good start, but it's relying on a `last_login` timestamp that might not exist for service accounts or API users. That's a common data quality gap in these logs. You should also join against your actual provisioning source, like your HRIS feed, to catch accounts that exist in JumpCloud but were terminated months ago in the source of truth. Otherwise, you're just cleaning up based on noisy activity data.
The real cost isn't just the dormant accounts you find, it's the engineering hours to build and maintain this hygiene script. If you have to run this monthly, you've just created a new, manual ETL job. Factor that labor into your TCO analysis against alternatives.
We're looking at moving SCIM provisioning logic back into our own code and using a lighter-weight service, because the platform fee makes the "managed" part of this service less valuable.
—davidr
Good point about the manual ETL job. That's a hidden cost I hadn't thought about.
I'm working on my own user audit script in Terraform, pulling from AWS IAM, but joining with HRIS data feels complex. Do you have any example of how you'd structure that data pipeline cleanly? I'm worried about building something too brittle.
The shift from "managed service" to "build vs. buy" you mentioned is exactly where I'm stuck now.
That SQL filter is a good start, but it's relying on a `last_login` timestamp that might not exist for service accounts or API users. That's a common data quality gap in these logs. You should also join against your actual provisioning source, like your HRIS feed, to catch accounts that exist in JumpCloud but were terminated months ago in the source of truth. Otherwise, you're just cleaning up based on noisy activity data.
The real cost isn't just the dormant accounts you find, it's the engineering hours to build and maintain this hygiene script. If you have to run this monthly, you've just created a new, manual ETL job. Factor that labor into your TCO analysis against alternatives.
We're looking at moving SCIM provisioning logic back into our own code and using a lighter-weight service, like Auth0 or a simple OIDC provider, for authentication only. The math starts to change quickly when you separate the directory from the IDP.
You're right to flag the data quality gap. We ran into the same issue where our `last_login` field was null for nearly 40% of entries, mostly service accounts tied to CI/CD pipelines. Joining with HRIS is ideal but introduces latency.
Our compromise was to tag the source of creation in the identity provider itself at provisioning time - 'HRIS', 'SCIM', 'MANUAL', 'SERVICE'. Our cleanup script then uses a tiered logic: for SERVICE and SCIM sources, we look at last API call or associated resource activity in our cloud logs instead of login. It's not perfect, but it reduces the manual review burden.
That separation of directory and IDP you mentioned is key. We found the cost of maintaining that logic was still lower than the platform fee increase, but it required a dedicated, lightweight service account governance process. Have you quantified the operational overhead of your new SCIM logic versus the old bundled cost?
Spreadsheets or it didn't happen.
That "set it and forget it SaaS" bite is exactly why I keep preaching about owning your automation substrate. When the bill jumps, you're stuck reacting. If your user hygiene script is running on someone else's cloud runners, you're just paying twice - once for the tool and once to clean up the tool's bill.
Your SQL audit is the right first move, but it's a reactive cost. The real fix is baking that lifecycle check into the provisioning pipeline itself, so a stale account can't even exist. Tie your SCIM source directly to a de-provisioning workflow in your own systems, not just a quarterly report.
null
Oh, the "Platform" add-on fee. Classic move. Been there with other services. Your baseline step is solid, but don't forget to check your contract's auto-renewal clause. That's where they'll get you if you're on autopilot.
Your SQL filter is the right spirit, but you'll miss a ton of stale accounts without HRIS data. We ended up tagging every account with a `source_system` at creation, so we can apply different logic for HRIS users vs. service accounts. Made our audit way less noisy.
The real kicker is turning that one-off script into a scheduled job. That's when the hidden labor cost hits.
NightOps
Ooh, that baseline step is so smart. I do something similar for any of our marketing automation tools when pricing changes hit. The per-user price is the headline, but the real sticker shock is always in the total bill once you add back the features you can't live without.
Your SQL filter is a great tactical start for the audit, but you're going to hit the same data quality snag we did with our email platform's user log - those service accounts never have a `last_login`. We ended up creating a separate tag or attribute at creation for any non-human identity, which then triggers a cleanup based on last activity from our system logs, not directory logins. It adds a setup step but makes the ongoing audit so much cleaner.
Has your team modeled what happens to that total bill if you drop down a tier and lose, say, one specific module? Sometimes that's the painful but necessary lever to pull.
test everything twice
Yep, got that same email. Your action plan is the right start, but let me give you the reality check from someone who's been through this cycle three times now.
Your SQL filter will catch low-hanging fruit, but as others have pointed out, `last_login` is a myth for half your directory. You need to pivot from reactive auditing to a proactive source of truth. That means building a simple, internal registry that *you* control - a small Postgres table or even a flat file in Git - that defines what *should* exist. Everything in JumpCloud is just a sync target. If an identity isn't in your source registry, it gets deprovisioned. No monthly script needed.
The real budget adjustment isn't just cleaning users; it's accepting that you now need to budget engineering hours to own the provisioning logic you thought you were outsourcing. The TCO math only works if you stop treating the directory as a system of record and start treating it as a render target.
I've lived this exact transition, and the key insight we had was quantifying the "lighter-weight service" tradeoff. Moving SCIM provisioning logic in-house shifts the cost center but doesn't eliminate it. You're trading a predictable platform fee for variable, often underestimated, engineering sprints.
Our TCO analysis included a full-time-equivalent multiplier for the first two quarters of building and stabilizing the internal registry and sync workers. The break-even point was 18 months out, which only made sense because we projected further annual price increases from the managed service.
The critical caveat is that this only works if your HRIS feed is itself a reliable source of truth. If you're joining against a messy employee directory, you've just moved the data quality problem upstream.
Your baseline step is critical. Model the total bill with the required platform add-on, but also project it forward 3 years with your expected headcount growth. That's where the real shock hits.
> Audit user lifecycle hygiene: This is now a direct cost center.
Exactly. The hourly cost to build and maintain that audit script needs to be in your model. Most teams underestimate it by 50%.
Consider this: if you have to dedicate 4 hours a month to manual cleanup and script updates, that's nearly half a work week per year. Add that labor cost to the new JumpCloud invoice. Does the TCO still make sense, or does it push you past the build-in-house break-even point?
Show me the bill
That 50% underestimate on labor is optimistic. I've seen teams blow a full sprint building these audit scripts, only to find the maintenance burden eats 8-10 hours a month when you factor in exceptions and schema changes. Your 4-hour estimate assumes clean data, which never happens.
>Add that labor cost to the new JumpCloud invoice.
That's the right math, but you're missing the cost of getting it wrong. If your script deletes a service account tied to a critical pipeline, the outage cost dwarfs the license savings. The real TCO includes risk, not just hours logged.
-- bb
Great point about the auto-renewal clause. That's often the trapdoor for these incremental fee hikes.
I'd add that tagging at creation is the cleanest approach, but you also need a process for those existing, un-tagged accounts from before you had this system. We found a phased clean-up worked best, starting with the most obviously stale ones.
Stay constructive
Yep, joining with the HRIS feed is a must. We tried the audit-only approach and kept finding "ghost" accounts from people who'd left 6+ months prior because our sync was one-way.
That move to separate the directory from the IDP is exactly where we landed. The hidden cost in the "lighter-weight service" route, though, is all the edge cases in the SCIM spec you now own - handling soft deletes, custom attributes, and partial updates. It's not just a simple sync worker.
Still, owning that logic means you control the source of truth and can finally tag service accounts properly at creation, which solves the `last_login` problem for good.
Prompt engineering is the new debugging