Okay, I need to get this off my chest because I just finished another painful budgeting cycle. We've been running QRadar for about 18 months now, and while the product itself is... fine... the pricing feels like a black box.
I came from a world of SaaS tools with clear per-user or flat-fee models, so maybe I'm spoiled. But here, it's based on "Events Per Second" (EPS). That sounds straightforward until you realize how many variables are at play. Your license tier dictates your EPS capacity, but then you have to factor in things like log sources, flows, and any custom parsing. One misconfigured noisy device can push you over your commit, and the overage charges are no joke. It feels punitive, like you're being penalized for actually using the tool to monitor your environment. It's the opposite of predictable scaling.
Has anyone else hit this wall? We had a project that increased our normal EPS by about 15% for a two-week period. The cost implications were stressful to model beforehand and painful to justify after the fact. It creates this perverse incentive to *not* ingest certain logs because you're afraid of the bill. In a security tool, that's a bad alignment of incentives.
I'm all for paying for value, and I understand complex products have complex costs. But this model feels designed to obscure true TCO until you're already locked in. I'd love to hear how others are navigating this. Are you just constantly throttling? Do you have a magic formula for forecasting? Or have you found ways to make the licensing team work with you on more flexible terms?
—kc
Sample size matters.
You're not spoiled, you're just seeing the licensing bait-and-switch. That "fine" product is intentionally coupled to a punitive financial model.
The EPS trap isn't an accident, it's a feature. It forces you into constant capacity management, which is a security team's job, not a finance team's job. You mentioned the perverse incentive to not ingest logs - I've seen three separate audits where teams excluded verbose but useful auth logs purely to stay under commit. Guess what those environments missed?
Did your post-mortem for that two-week project include the cost of engineering hours spent modeling the EPS impact? That's the real margin for them. You pay for the product, then you pay your people to avoid paying them even more.
- Nina
You've hit on the exact operational cost that often goes uncaptured in TCO models. The "constant capacity management" you describe isn't just a financial drain, it's a direct tax on engineering and security focus.
Beyond modeling EPS impact for projects, consider the ongoing burden of maintaining that model. Every infrastructure change, new service deployment, or even a version upgrade for a critical application requires a re-evaluation of its EPS signature. This creates a measurable drag on velocity. Teams often implement secondary monitoring, like a Prometheus gauge for estimated EPS from log sources, just to provide internal cost visibility and prevent budget surprises. The tooling meant to provide observability itself becomes a source of operational opacity.
That secondary monitoring stack represents pure overhead, duplicating effort to manage the commercial product's constraints.
You think that's by accident? That pricing model is the product. The "security" part is just the wrapper.
>one misconfigured noisy device can push you over your commit
Exactly. And who's the first call you make when you're in breach? Your account manager, who just happens to have a ready-to-sign amendment for more capacity. It's a feature, not a bug. Your stressful two-week project was a revenue opportunity for them.
The real joke is calling it "opaque." It's perfectly clear if you follow the incentives. They sell you a small pipe, then make you terrified of what might flow through it. The goal isn't to help you see everything, it's to make you constantly calculate the cost of seeing anything new.
If it's free, you're the product. If it's expensive, you're still the product.