Per-user upload and download throughput at 5-second resolution — built into the Web Admin Console, no separate dashboard to install.
Most SFTP servers can tell you what happened. They can't tell you what's happening. When an operations team gets a ticket like “the file transfer is slow today” or “something is saturating the link,” the only available evidence is a static audit log of completed transfers — and even that requires SSH or SQL to query.
Knowing the answer often means tailing log files, running ad-hoc queries against the audit table, or installing a separate monitoring stack (Prometheus, Grafana, Telegraf) just to chart what the SFTP server already knew. That's a lot of moving parts for a question the file server should be able to answer itself.
Stylus SFTP Server's Activities tab answers the question in three live charts — bandwidth, transfer events, and session activity — all per-user, all from a single page in the Web Admin Console.
Range and user filters in the toolbar drive every chart. Auto-refresh every 10 seconds. Drill from "all users" down to one user with two clicks.
Pick Last hour, Last 24 hours, Last 7 days, or Last 30 days from the toolbar combo. The chart adjusts its bucket size automatically — 5-minute buckets at one hour scale, 1-hour buckets at one day, daily buckets at one month — so the chart never crowds and never loses resolution.
The user combo lists everyone with measurable activity. Pick a username and all three charts re-render for just that account. Investigating “is alice the one saturating the link” takes two seconds.
A lock-free byte counter tapped at the storage layer, sampled every 5 seconds, charted live in the Web Admin.
Every protocol — SFTP, FTP, WebDAV, the browser portal — routes file bytes through the same Storage Backend interface. We wrap that interface's input and output streams with a counting filter that calls a per-user atomic counter on every read or write. One hook covers every protocol.
The byte counter is an AtomicLong per user. Each chunk write is one atomic increment — about ten nanoseconds. There's no map mutation per write (the per-user entry is created once and reused), no DB call on the hot path, and no thread synchronization. The throughput cost of measuring is effectively unmeasurable.
A daemon thread atomically snapshots the per-user counter values and writes one row to sftp_throughput_samples in the audit database for every user with non-zero activity in that window. Reset semantics on the counter mean the next sample is a true delta, not a cumulative; restart-safe with zero edge cases.
A daily task collapses raw 5-second samples older than 24 hours into 1-hour aggregates — preserving the rate math exactly — and deletes anything older than 30 days. Steady-state storage is small even on busy installations: tens of MB per month for typical concurrency.
sftp-server.xmlSensible defaults out of the box. Two knobs if you need to tune.
Set -Dstylus.sftpserver.bandwidth.disabled=true on the JVM command line and the entire subsystem is inert. No counter increments, no map mutations, no sampler thread, no DB writes. The Activities tab still loads — it just shows empty charts. Useful when you need to rule the feature out as a contributor to an unrelated incident, without editing the config file.
Bursts and saturation events visible to the second, not averaged across hours.
"Who's saturating my pipe right now" is a one-click answer.
Bandwidth, upload/download events, session counts — all in the same view, all auto-refreshing.
Daily compactor folds raw samples into hour aggregates so a month of detail stays cheap.
One JVM property disables the entire subsystem without editing the config file.
No Prometheus, no Grafana, no Telegraf. The file server measures itself and shows you.
Free evaluation key, full feature set, no time limit on the install — just an honest evaluation period for production use.