Bandwidth usage
How much network traffic the agents, the master, AI analysis and an open panel use, how the report interval and the number of servers change it, and how to reduce it.
The numbers on this page were measured with 3R Monitor 1.0.5 on Debian 12 servers running Nginx, MariaDB, PHP-FPM, SSH and cron. They were counted at the network interface, so they include the TCP/IP overhead. Versions 1.1.0 and 1.1.1 send the same reports, with only a few small fields added (1.1.1 adds the byte counters of each network interface), so they still apply; the vulnerability downloads, which 1.1.0 reduced, are estimated for 1.1.0. On your servers the numbers will differ a little with the number of services, disks and processes, but the order of magnitude is the same.
At a glance
| What | Traffic |
|---|---|
| One agent, default interval (3 s) | About 2.4 MB per hour: 58 MB a day, 1.7 GB a month |
| One agent, interval 10 s · 30 s · 60 s | 18 · 7.4 · 4.5 MB a day |
| A busy website with request statistics (100 requests per second) | About 46 MB a day more |
| The master | The sum of its agents, plus a few MB a day of its own (1 to 10 MB for the vulnerability checks) |
| AI analysis, if you turn it on | At most about 10 MB a day with the default token limit |
| An open panel | About 0.2 MB per server per hour, only while the page is open |
| An HTTP monitor | The size of the page, at every check |
Whether the panel is open doesn't change what the agents send. Agents report at their interval whether or not anyone is looking. An open panel only adds the traffic between the master and that browser.
Agents
What a report contains
At every interval, the agent sends one report to the master: CPU, memory, disks, network, services, and the new lines of the access logs. To keep it small:
- the report is compressed (gzip);
- the parts that rarely change (listening ports, top processes, software, certificates) are only sent when they changed, plus a full report every 10 minutes;
- the connection to the master stays open between reports, so a report doesn't need a new connection (with intervals up to 90 s).
With the default interval, a report is about 1.4 KB up and the master's reply about 0.6 KB down. About 70% of an agent's traffic is upload, from the server to the master.
The report interval
Set it for all servers in Settings → Default thresholds → Agents → Agent report interval (s), or for one server in its own settings (Servers → Settings → Report interval (s)). The agent picks up the change with its next report.
Traffic of one agent, with an idle website:
| Interval | Per hour | Per day | Per month (30 days) |
|---|---|---|---|
| 1 s | 7.0 MB | 168 MB | 5.0 GB |
| 3 s (default) | 2.4 MB | 58 MB | 1.7 GB |
| 10 s | 0.75 MB | 18 MB | 540 MB |
| 30 s | 0.31 MB | 7.4 MB | 220 MB |
| 60 s | 0.19 MB | 4.5 MB | 135 MB |
| 300 s | 0.05 MB | 1.2 MB | 36 MB |
Traffic doesn't fall exactly in proportion to the interval: every report has a fixed cost (HTTP headers, TCP), and with longer intervals more data has changed between two reports. Even so, going from 3 to 10 s saves about 70%.
What a longer interval changes:
- The live charts, the map and the server cards update less often.
- With the default Offline after (s), a server counts as offline after 3 intervals without a report at the earliest: at 60 s, after 3 minutes. If you set a server's own Offline after (s), make it at least 3 times its interval.
- CPU and memory alerts still wait for Seconds before alerting (120 s by default), with fewer measurements in that time.
Request statistics
When the server has Apache or Nginx access logs, every report also carries how many requests each IP made since the last report (at most 300 IPs per report), and once a minute the paths and User-Agents of the 100 most active IPs.
| Website load | Extra traffic per day |
|---|---|
| Few visits | Close to 0 |
| 10 requests per second (about 860,000 a day) | About 11 MB |
| 100 requests per second (about 8.6 million a day) | About 46 MB |
Because the lists are capped, the traffic grows much more slowly than the number of requests. If you don't need request statistics on a server, set access_logs = off in its /etc/3rmonitor/agent.conf (see Configuration files).
HTTP or HTTPS
Over HTTPS with HTTP/2, for example with install.sh --https, the traffic is about the same as over HTTP: 2% more in the test. Use HTTPS whenever the master can be reached from the internet (see HTTPS).
With intervals over 90 s, every report opens a new connection. Over HTTPS this adds a TLS handshake of about 4 to 6 KB per report, which at 300 s is still under 3 MB a day.
Occasional transfers
| What | When | Size |
|---|---|---|
| Installing the agent | Once | About 15 MB (the program, downloaded from the master) |
| Agent update | Once per new version | About 15 MB |
| Software inventory, for the vulnerability checks | The first report, after software changes, and at least once a day | A few KB to a few tens of KB, compressed |
| Blocklist / allowlist rules | Only when they change, and only on servers where blocking is on | A few KB; more if you block whole countries |
| Public IP lookup at 1.1.1.1 | Every 15 minutes, only if the public IP isn't on a network interface or in the cloud metadata | About 5 KB each time, 0.5 MB a day. Avoid it with public_ip = off or a fixed IP. |
The agent on the master
The agent installed together with the master (Master + agent) reports to 127.0.0.1: its traffic never leaves the server.
The master
The master receives what its agents upload, and sends them their replies. With N servers at the same interval, multiply the agent numbers by N:
| Servers (interval 3 s) | Into the master | Out of the master | Total per month |
|---|---|---|---|
| 10 | 17 MB/h | 7 MB/h | 17 GB |
| 50 | 85 MB/h | 35 MB/h | 87 GB |
| 100 | 170 MB/h | 70 MB/h | 174 GB |
As a bandwidth, 100 servers at 3 s are about 0.5 Mbit/s on average. At 10 s the same table is about 70% lower.
Many cloud providers only charge for outbound traffic. For agents, that is mainly the reports (the upload). For the master, it is the replies to the agents and what open panels receive.
Background traffic of the master
| What | When | Traffic |
|---|---|---|
| Vulnerability checks, first activation | Once, on a new installation | It catches up on the CVE changes of the last 48 hours: up to about 20 MB in the first minutes |
| Vulnerability checks, afterwards | CVE changes every 10 minutes, KEV list every 6 hours, end-of-life data daily, a check of every server every 6 hours | About 1 to 10 MB a day, mostly the CVE records that changed: each one is downloaded once a day, about 2.5 KB on the network, and 300 to 3,000 change on a usual day. Up to version 1.0.12, the same records were downloaded again every hour, about 40 MB a day. |
| AI analysis | Reports, vulnerability assessment, alert explanations, the assistant and on-call, only if you turn it on | Text sent to and received from your model provider: about 4 bytes per token, so the default Daily token limit of 2 million tokens means at most about 10 MB a day. A local Ollama on the master uses no internet traffic. |
| IP-to-country database (DB-IP) | Once a month | About 4 MB |
| Update check on 3rsoft.com.pa | Every 6 hours | About 7 KB each time |
| Alert emails | When something happens | A few KB per email |
The vulnerability checks can be turned off in Settings → Vulnerability checks, the database update in Settings → Map, and AI analysis in AI → Settings. See Security and privacy.
The panel in the browser
While the page is open
An open panel keeps one live connection to the master (Server-Sent Events). The master pushes:
- after every report of every server you can see, a short summary of that server;
- after every monitor check, its result;
- a heartbeat every 15 seconds.
The connection is compressed: in the test, it carried about 1/20 of the uncompressed size. Even so, every update is a small network packet of its own, so the total grows with the number of servers and with how often they report:
| Servers shown (interval 3 s) | Per hour | 8 hours a day, for a month | Around the clock, for a month |
|---|---|---|---|
| 1 | 0.2 MB | 50 MB | 150 MB |
| 10 | 1.6 MB | 390 MB | 1.2 GB |
| 50 | 8 MB | 1.9 GB | 5.8 GB |
Servers with a busy website count about 1.5 times as much. With servers at 10 s, it is about a third.
- A server's details page (or its side panel on the Overview) also receives that server's full data at every report: about 0.3 MB more per hour for that server.
- The page is only counted while it is open. A tab in the background or a minimized window stays connected: close the tab to stop the traffic.
- A display screen that runs around the clock (see Display mode) also does a full sync every 5 minutes and rebuilds the page every 6 hours, which adds little. A screen that shows 10 servers around the clock uses about 1.2 GB a month.
- A share link limited to some groups only receives the updates of those groups.
- Keep compression on: a reverse proxy that removes it makes the connection about 8 times bigger.
Opening the panel
The first time, the browser downloads the interface: about 320 KB, plus 90 to 100 KB for Spanish or Chinese. It keeps it in its cache until the master is upgraded. After that, opening the panel only downloads the current data: a few KB, plus about 1.5 KB per server.
Monitors
The master runs the monitors itself, so their traffic is between the master and the monitored address:
| Type | Per check |
|---|---|
| HTTP(S) | The whole response, up to 2 MB (compressed if the site supports it), plus about 1 KB |
| SSL certificate | A TLS handshake, about 5 KB |
| TCP port, ping, DNS | Under 1 KB |
For HTTP monitors, the page size matters most. A page of 100 KB checked every 60 seconds is 144 MB a day, for the master and for the website. Point HTTP monitors at a small address, such as a health check URL or a light page, and use a longer interval for large pages.
How to reduce it
- Raise the report interval: 10 s instead of 3 s saves about 70% of the agent traffic, and alerts still arrive within seconds. You can keep 3 s on important servers and use 30 or 60 s on the others.
- Turn off request statistics where you don't need them:
access_logs = off. - Close panel tabs you don't need. For wall screens, use a share link limited to the groups you want to show.
- Use light addresses for HTTP monitors.
- Turn off what you don't use: vulnerability checks, the monthly IP database update, AI analysis (or lower its Daily token limit).
Estimate your own
Per day, roughly:
- Agents: number of servers × the value per day from the interval table, plus the request statistics of busy websites.
- Panel: for each open screen, hours open × servers shown × 0.2 MB (at 3 s; a third at 10 s).
- Monitors: for each HTTP monitor, page size × checks per day (86,400 ÷ interval).
Example: 20 servers at 10 s, one of them a website with 10 requests per second, the panel open 8 hours a day on one computer, and 10 HTTP monitors of 20 KB every 60 s:
| Per day | |
|---|---|
| Agents: 20 × 18 MB + 11 MB | 371 MB |
| Panel: 8 h × 20 servers × 0.07 MB | 11 MB |
| Monitors: 10 × 20 KB × 1,440 | 288 MB |
| Total | 670 MB (about 20 GB a month) |