The Activities tab in the Web Admin Console shows three charts that refresh every ten seconds. They look simple — coloured lines trending over time — but each line is sourced from a different place in the server, and each one answers a different operational question. This post walks through the three charts, explains where the data comes from, and describes what a spike (or a flatline) actually means.
Chart 1 — Upload & Download Activity
Two lines: green for uploads, blue for downloads. The Y-axis is a count of completed file transfers per time bucket.
The data source is the sftp_audit table — the same audit trail that powers the audit feature. Every time a client finishes uploading a file, the server writes an UPLOAD_COMPLETE event. Every finished download writes a DOWNLOAD_COMPLETE event. The chart counts those events, bucketed by the time range you selected in the toolbar.
What a spike means. A sudden jump in the green line means many uploads landed in a short window — a batch job kicking off, a partner pushing their nightly extract, or an automated pipeline flushing a queue. A spike in blue means something downstream (or someone in the Web File Portal) pulled a burst of files at once.
What a flatline means. Zero uploads or downloads for an extended period might be normal (overnight quiet), or it might mean a scheduled job didn't run. The chart answers the question before anyone opens a ticket: “has anything moved in the last hour?”
The count is keyed on completed transfers only. An upload that fails mid-stream (client disconnects, disk quota exceeded, network timeout) never fires UPLOAD_COMPLETE and never increments the line. That's intentional — you see what landed, not what was attempted.
Chart 2 — Session Activity
One line, orange. The Y-axis is a count of authenticated sessions per bucket.
This line counts AUTH_SUCCESS events from the audit table — not raw TCP connections. A port scan or an SSH banner probe won't show up here because those connections never authenticate. The chart counts the moment a user successfully logged in: password verified, MFA passed, public key accepted.
What a spike means. A burst of sessions usually means a batch of scripted clients connecting in parallel. If the spike doesn't correlate with an upload or download spike in Chart 1, the sessions connected but didn't transfer anything — that's worth investigating. It could be a misconfigured automation client that authenticates, finds nothing to do, and disconnects.
What a slow climb means. A gradual upward trend across days or weeks means your user base is growing, or existing users are reconnecting more frequently. Combined with the bandwidth chart (below), it tells you whether you're adding sessions that actually move data or just adding connection overhead.
Chart 3 — Bandwidth
Two lines again: green for upload rate, blue for download rate. The Y-axis is bytes per second, and it auto-scales between B/s, KB/s, and MB/s depending on the range.
This chart does not come from the audit table. It has its own data source: the sftp_throughput_samples table. Here's why.
The audit trail records events — “a file arrived” — but not the shape of the transfer in flight. To measure throughput, the server wraps every I/O stream (across SFTP, FTP, FTPS, WebDAV, and the browser Portal) with a byte counter that increments on every chunk. A sampler thread wakes up every five seconds, drains those counters, records wall-clock elapsed time alongside the byte totals, and writes one row per active user into sftp_throughput_samples.
The rate math is SUM(bytes) / (SUM(elapsed_ms) / 1000). That formula uses the actual elapsed time between ticks, not a nominal five-second constant. If the JVM pauses for garbage collection and a tick stretches to six seconds, the denominator is 6000, not 5000. The rate stays accurate under load — exactly when accuracy matters most.
What a spike means. A sharp green spike is a large file landing fast — or many medium files landing simultaneously. Filter the chart to a single user (the dropdown is in the toolbar) and you'll see who is saturating the link. This is the “who's eating the bandwidth right now?” answer, and it takes two clicks.
What a plateau means. A flat line at a consistent rate usually means a single large transfer in progress. The height of the plateau tells you the sustained throughput. If it's lower than your network allows, the bottleneck is somewhere else — disk I/O, database write speed, or the client's upload capacity.
Time ranges and rollup
The toolbar offers four time ranges: last hour (5-minute buckets), last 24 hours (hourly), last 7 days (daily), and last 30 days (daily). Behind the scenes, raw 5-second throughput samples are compacted after 24 hours into hourly aggregates, and everything older than 30 days is deleted. Steady-state storage is roughly 1 MB per active user for the full 30-day window.
The rollup preserves rate accuracy. When hundreds of raw rows collapse into one hourly row, the sum of bytes and the sum of elapsed milliseconds both carry forward. The resulting average MB/s for that hour is mathematically identical to what you'd get from the raw data.
What it replaces
Without built-in charts, the standard approach is an external monitoring stack — Prometheus scraping a metrics endpoint, Grafana rendering dashboards, Telegraf collecting OS-level counters. That works, but it's a separate system to install, configure, secure, and maintain. The Activities tab ships inside the server. No agents, no exporters, no separate dashboard URL. Open the Web Admin, click Activities, and the data is already there.
For a deeper look at how the bandwidth pipeline is architected — lock-free counters, the drain-and-reset sampler, the daily compactor, and the JVM kill switch — see the real-time bandwidth monitoring product page.