QRadar EPS/FPM License Pool Over-Allocated: Causes, Diagnostics, and Fixes
How to troubleshoot the QRadar license pool over-allocation error, find the log source or host driving it, and decide between reallocation and a license increase
Proactive Security for the AI Era
NodeZero continuously and autonomously pentests infrastructure, identity, cloud, and now web applications, chaining weaknesses across every domain the way real attackers do. Every finding ships with replayable proof showing exploitable business impact, not theoretical risk.
QRadar administrators run into this error two different ways, and the fix depends on which one you actually have. The first is a pure configuration problem: someone assigned EPS or FPM allocation to individual managed hosts in License Pool Management, and the sum of those allocations exceeds what the Console's overall license actually grants. When that happens, QRadar blocks the Log Activity and Network Activity tabs and shows the message "The EPS or FPM license pool is over-allocated. Please contact your administrator." The second is a throughput problem: real event or flow volume from your log sources is pushing at or past the licensed EPS/FPM rate, independent of how the pool is divided up. Both get called "license pool over-allocated" in practice, but the diagnostics and the fix are not the same, so the first job is figuring out which condition you are looking at.
Causes: why the license pool ends up over-allocated
IBM's own documentation on this error points to a specific administrative mechanic: from QRadar 7.2.6 onward, the Console's overall EPS and FPM license lives in a shared pool, and administrators divide that pool across managed hosts (event processors, flow processors, data gateways, event collectors) in the License Pool Management interface. That interface is supposed to stop you from allocating more than the Console license actually holds, but in practice the over-allocated state still shows up, usually from one of these root causes.
Per-host allocation arithmetic exceeds the Console total
An administrator increased one host's EPS or FPM allocation to handle a spike or a new log source, without first reducing another host's allocation by the same amount, so the total across all hosts now exceeds the Console's licensed pool.
A new log source was onboarded without a licensing review
A log source (a firewall cluster, a new EDR integration, a cloud audit log feed) was pointed at QRadar and started sending events without anyone updating the receiving host's EPS allocation or checking whether the pool had spare capacity to absorb it.
A misconfigured or noisy log source is bursting well above its normal rate
A single source, often a device stuck in a logging loop, a chatty debug setting left enabled, or a misconfigured syslog forwarder, is sending events at several times its normal volume, pushing that host's actual EPS past what is allocated to it even though the pool total on paper still looks fine.
Genuine sustained EPS/FPM growth has outpaced the licensed pool
Event and flow volume has grown organically across the environment (more endpoints, more cloud services, more network segments feeding flow data), and the deployment's total licensed EPS/FPM capacity, not just its allocation across hosts, is now genuinely too small for current traffic.
Diagnostics: confirming which condition you have and what is driving it
Before touching any allocation values, use QRadar's own admin console to separate an allocation-arithmetic problem from a real capacity problem, and to identify which host or log source is actually responsible.
Open License Pool Management and compare totals
Go to Admin > System and License Management > Licenses > License Pool Management. This view lists every managed host with its EPS Allocation and FPM Allocation (the capacity assigned to it) alongside its Average EPS and Average FPM (actual usage over the trailing 30 days). Add up the allocation columns and compare the total against the Console's overall licensed EPS/FPM: if the sum of allocations already exceeds the license, you have an allocation-arithmetic problem regardless of actual traffic.
Check average versus peak usage per host
In the same License Pool Management view, click into an individual host to see its peak EPS/FPM rates over the past 30 days, not just the average. A host whose average sits comfortably under its allocation but whose peak repeatedly spikes close to or above it is the signature of a bursty log source, not a sizing problem.
Identify the log source(s) driving the volume
Use the Log Activity tab (once accessible) or the Log Sources list under Admin > Data Sources > Log Sources, sorted or filtered by event rate, to find which individual sources are contributing the most events to the affected host. A single device or feed responsible for a disproportionate share of that host's EPS is the one to investigate first.
Check per-host license enforcement, not just the pool total
Each managed host also has its own hardware-based EPS/FPM ceiling in addition to whatever it is allocated from the pool. Confirm the host's allocation is not just under the pool total but also within what that appliance type can process, since an allocation that is valid on paper can still exceed hardware capability.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixes: resolving the over-allocation
Which fix applies depends directly on what the diagnostics showed. Try reallocation and tuning first since they require no vendor engagement; only pursue a license increase once you have confirmed the pool genuinely lacks spare capacity.
Reallocate license capacity across managed hosts
In License Pool Management, reduce the EPS or FPM allocation on hosts running well under their assigned capacity (based on the average and peak figures from diagnostics) and shift that freed capacity to the host that is over-allocated or under pressure. EPS changes must be made in multiples of 100 and FPM changes in multiples of 5,000, and the new total across all hosts must stay at or under the Console's overall license.
Tune or filter the noisy log source
If diagnostics identified a specific device or feed driving an abnormal burst, correct it at the source: fix the logging loop, disable an over-verbose debug or audit setting, or adjust the device's own log level. Where the source cannot be tuned directly, use a QRadar log source extension, event filter, or routing rule to drop or downsample low-value event types before they count against EPS.
Apply a temporary rate limit while a permanent fix is pending
If the noisy source cannot be corrected immediately, use available log source or forwarding controls to throttle its rate as a stopgap, buying time without permanently discarding events, while the underlying misconfiguration or the licensing conversation is resolved.
Request a license capacity increase from IBM
If diagnostics show sustained average usage genuinely approaching or exceeding the total licensed EPS/FPM pool, with no spare capacity to reallocate from underused hosts, reallocation and tuning will not resolve it. Open a request with your IBM account team or IBM Support for a license capacity increase sized to your current and near-term expected volume.
Validation: confirming the fix actually holds
Clearing the immediate error message is not the same as confirming the underlying condition is resolved. After making changes in License Pool Management, deploy the configuration change (Advanced > Deploy Full Configuration if a simple deploy does not apply the new allocations, keeping in mind this can briefly pause event collection) and confirm the Log Activity and Network Activity tabs load without the over-allocation message. Then keep watching the same data you used to diagnose the problem: check that the sum of per-host allocations stays under the Console's total license, and monitor each affected host's Average EPS/FPM over the following days rather than relying on a single point-in-time check, since a fix that only addresses today's burst will not hold if the source that caused it starts sending at the same elevated rate again. If the fix involved filtering or throttling a log source, confirm in Log Activity that the source's event rate has actually dropped and that no event categories you still need for detection were inadvertently filtered out.
Failure cases: when the fix does not hold
QRadar includes burst handling designed to absorb short-term spikes above allocated EPS/FPM without immediately discarding events, which is why a brief burst does not always translate into visible data loss. That tolerance is built for temporary spikes, not for a deployment that is consistently running at or above its licensed capacity. If the real cause is sustained growth rather than a single misconfigured source, reallocating capacity between hosts only moves the problem around the same fixed total pool. Tuning a single noisy source helps only if that source was actually the majority driver; if volume growth is distributed across many sources, no single fix will bring the total back under license. When a deployment operates above its licensed EPS/FPM for extended periods, the practical risk is that events queue and processing falls behind, and if the underlying volume is not brought back under the license or the license itself is not increased, the condition recurs immediately after any reallocation and continues to show as an over-allocation warning or as data that is delayed in appearing in searches and correlation.
Escalation criteria: when to open an IBM support case
Reallocation and log source tuning resolve most instances of this error, since they are usually genuine allocation mistakes or a single noisy source. Escalate to IBM Support when your diagnostics point clearly at a capacity shortfall rather than a configuration error. Gather this before opening the case so IBM can size a resolution on the first pass:
A current license pool report
An export or screenshot of License Pool Management showing every managed host's EPS/FPM allocation alongside its Average and peak usage, and the Console's total licensed EPS/FPM for comparison.
EPS/FPM usage history, not just a snapshot
Trend data covering at least the last 30 days per host, showing whether usage is a one-time spike, a steady climb, or already flat at the licensed ceiling, since that distinction determines whether the answer is tuning or a license increase.
A list of top log sources by volume
The highest-EPS log sources feeding each affected host, so IBM can help assess whether the volume reflects legitimate new coverage that should be licensed for, or a misconfiguration that should be fixed at the source instead.
The bottom line
Start every EPS/FPM over-allocation error the same way: check License Pool Management before touching anything. If the per-host allocations simply do not add up to the Console's licensed total, or a single log source is bursting well above its normal rate, you can usually fix it yourself by reallocating capacity or tuning the source. If 30 days of usage history shows sustained volume genuinely at or above the licensed pool with no spare capacity anywhere to reallocate from, stop reallocating and open a license capacity request with IBM instead, since no amount of internal rebalancing creates capacity that was never licensed in the first place.
Frequently asked questions
What does the QRadar EPS or FPM license pool over-allocated error actually mean?
It means the events-per-second (EPS) or flows-per-minute (FPM) capacity assigned to individual managed hosts in License Pool Management adds up to more than the total the Console is actually licensed for, which blocks the Log Activity and Network Activity tabs until an administrator corrects the allocation or the underlying capacity shortfall.
What causes a QRadar license pool to become over-allocated?
The most common causes are an administrator raising one host's allocation without lowering another's to compensate, a new log source going live without a licensing review, a single misconfigured or noisy source bursting far above its normal rate, or genuine sustained event and flow growth across the environment outpacing the licensed pool.
How do I check current EPS/FPM usage against my QRadar license?
Go to Admin > System and License Management > Licenses > License Pool Management, which lists each managed host's assigned EPS/FPM allocation next to its actual average usage over the trailing 30 days, and lets you click into a host to see its peak rates over the same period.
Can I fix the over-allocation error myself without contacting IBM?
Yes, in most cases: if the pool total is fine but poorly divided, reallocating EPS/FPM from underused hosts to the affected one resolves it, and if a specific log source is bursting, tuning or filtering that source at its origin usually brings usage back under the allocated capacity without any vendor involvement.
What happens to events while the license pool is over-allocated?
QRadar has built-in burst handling intended to absorb short, temporary spikes above allocated EPS/FPM without immediately dropping data, but that tolerance is not unlimited: if the deployment runs above its licensed capacity for a sustained period rather than a brief burst, processing can fall behind and event visibility in searches and correlation can be delayed.
When should I open an IBM support case for this error?
Escalate once your diagnostics show sustained EPS/FPM usage genuinely at or above the total licensed pool with no spare capacity left to reallocate from other hosts, and bring a license pool report, at least 30 days of usage history per host, and a list of your top log sources by volume so IBM can size a license increase correctly.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.