Before you buy or build a SIEM, you need three numbers: how many events per second (EPS) your systems produce, how many gigabytes of logs that adds up to each day, and how much storage your retention period needs. They decide the hardware, and with many SIEMs they also decide the bill.
Enter your log sources below. The calculator starts from typical values for a 100-person company; replace them with your own counts, and with measured EPS if you have it.
The formula: GB per day = EPS × average event size in bytes × 86,400 ÷ 1,000,000,000. At an average of 500 bytes per event, every 100 EPS is about 4.3 GB per day.
SIEM sizing calculator
Sizes are raw, before compression. Real disk use depends on the SIEM: column stores compress logs heavily, while search indexes with replicas can need more space than the raw data.
How the calculator works
The math is simple, and you can check it by hand:
- Average EPS is the sum, for each type of source, of the number of sources times the average EPS of one source.
- Events per day is average EPS × 86,400, the number of seconds in a day.
- Raw GB per day is events per day × the average event size in bytes, divided by 1,000,000,000.
- Peak EPS is average EPS × your peak to average ratio. Ingestion must keep up with peaks, not with the average.
- Storage is GB per day × the number of days you keep, once for the fast (hot) tier and once for total retention.
From log sources to storage, with the example values
Each step is one multiplication you can check by hand
- Log sources134laptops, servers, firewalls, cloud accounts
- Average EPS272sources × EPS of each
- Events a day23.5 millionEPS × 86,400 seconds
- Raw logs a day11.8 GBevents × 500 bytes
- A year of logs4.3 TBGB a day × 365, before compression
EPS to GB per day, at a glance
At 500 bytes per event:
| Average EPS | Events per day | Raw GB per day | Raw GB per 30 days |
|---|---|---|---|
| 100 | 8.6 million | 4.3 | 130 |
| 500 | 43.2 million | 21.6 | 648 |
| 1,000 | 86.4 million | 43.2 | 1,296 |
| 2,500 | 216 million | 108 | 3,240 |
| 5,000 | 432 million | 216 | 6,480 |
| 10,000 | 864 million | 432 | 12,960 |
To go the other way, EPS = GB per day × 1,000,000,000 ÷ (event size × 86,400). At 500 bytes, 10 GB per day is about 231 EPS.
Typical EPS by device type
These are rough starting points for systems with security auditing turned on. Real numbers vary by a factor of ten or more depending on configuration, so treat them as placeholders until you measure.
| Source | Typical average EPS | What pushes it up |
|---|---|---|
| Workstation or laptop | 0.2 to 2 | Process and PowerShell logging, endpoint agents |
| Windows member server | 1 to 10 | Busy file shares, IIS, verbose auditing |
| Domain controller | 10 to 100+ | Number of users, Kerberos and logon volume |
| Linux server | 0.5 to 5 | auditd rules, web and application logs |
| Database server | 1 to 20+ | Logging every query or every login |
| Firewall or VPN gateway | 10 to 1,000+ | Logging every allowed connection, not just denies |
| Switch, router, wireless controller | 0.1 to 5 | Debug-level logging, port flapping |
| Cloud or SaaS account | 1 to 50 | Users, data-access events, storage access logs |
| Security console (EDR, antivirus, email) | 0.5 to 10 | Telemetry forwarding instead of alerts only |
Typical events per second, by type of source
Each bar spans the usual range. The scale grows tenfold at each line, so firewalls and domain controllers sit far above everything else.
Event size varies too. A typical syslog line from a network device is a few hundred bytes; a Windows event in its full form is often closer to a kilobyte. If most of your volume is Windows, raise the average event size to 800 or 1,000 bytes.
How to measure your real EPS
A week of real data beats any table. Three quick ways:
On a Windows server, count yesterday’s Security log events and divide by the seconds in a day:
(Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue).Count / 86400On a Linux server using the systemd journal:
echo "$(journalctl --since '24 hours ago' --no-pager | wc -l) / 86400" | bc -lOn a syslog server that already receives firewall logs, count the lines one source sent in a day and divide by 86,400. Divide the file size by the line count to get the average event size.
Measure on a normal working day and on a busy one, such as a patch night. The ratio between the two is your peak to average ratio. Without data, use 3.
Plan for peaks, not averages
Log volume is not flat. It spikes at the start of the working day, during patching and backups, and during an incident, which is exactly when you can least afford dropped events. Size ingestion (CPU, memory and the collection pipeline) for peak EPS, and size storage for the average.
Retention drives storage more than anything else
Daily volume times days kept is your storage bill. Retention usually comes from a rule rather than a preference:
- PCI DSS requires at least 12 months of log history, with three months immediately available. See our guide to PCI DSS logging requirements.
- CMMC and NIST SP 800-171 set no fixed period; many contractors keep a year. See CMMC SIEM requirements.
- HIPAA sets no log-specific period; many healthcare organizations keep audit records for six years to match its documentation rule. See HIPAA log retention.
One year of logs in two tiers
Example: the last 30 days on fast disks, the other eleven months on cheaper storage that can still be searched
Keep recent data on fast SSD or NVMe disks where searches and correlation run, and move older data to cheaper storage. Check that the cold tier is still searchable: some SIEMs make you restore archives before you can look at them, which turns a five-minute audit request into a day of work.
Why sizing changes the price
Many SIEMs bill by data volume: per gigabyte ingested each day, or per EPS. With those, every new firewall rule that logs allowed traffic, and every busy week, shows up on the invoice, and teams end up switching off logs they should keep. Other SIEMs, including UTMStack, price by the number of devices, so the estimate above changes the hardware but not the license. Our guide to SIEM cost explains the pricing models in detail.
How UTMStack sizes
UTMStack runs on one server for most organizations, and scales out across nodes for large ones. The single-server sizes on our system requirements page are planned for one month of hot storage:
| Size | Data sources | Data per month | CPU | Memory | Disk |
|---|---|---|---|---|---|
| Small | 50 | 120 GB | 4 cores | 16 GB | 150 GB |
| Medium | 120 | 250 GB | 8 cores | 16 GB | 250 GB |
| Large | 240 | 500 GB | 16 cores | 32 GB | 500 GB |
| Enterprise | 500 | 1 TB | 32 cores | 64 GB | 1 TB |
Multiply the disk by the number of months you want to keep hot. UTMStack stores logs in compressed column storage, and older data moves to a cold tier that answers the same searches without a restore. To size a larger deployment, talk to an engineer.
Frequently asked questions
What is EPS in a SIEM? Events per second: the number of log records your systems send to the SIEM each second, averaged over a day. It is the standard way to size SIEM ingestion and, for some products, to price it.
How do I convert EPS to GB per day? Multiply EPS by the average event size in bytes and by 86,400, then divide by 1,000,000,000. At 500 bytes, 1,000 EPS is 43.2 GB per day.
How many EPS does a firewall generate? Anywhere from about 10 to several thousand. The biggest factor is whether you log every allowed connection or only denied traffic and threats. Measure it from your firewall’s syslog output.
How much storage do I need for a SIEM? Raw GB per day times the number of days you keep data, adjusted for compression. For example, 500 EPS at 500 bytes is about 21.6 GB per day, or about 7.9 TB of raw data for a year.
How many EPS per employee should I plan for? There is no reliable rule. The example values in the calculator, for a 100-person office, work out to under 3 EPS per employee once servers, firewalls and cloud services are included, but busy firewalls or verbose endpoint logging can multiply that. Count sources instead, and measure.
