Repository navigation
statistics
The Statistics tab answers what the service has actually moved: how many transfers finished, how many failed, how much data went through, and how that is distributed over kinds and providers.
Everything on it is read from stored figures, so the page says the same after a restart as before one — unlike the counters in the Downloads toolbar, which are about this moment.
It is the first tab of Statistics & history, which you open from the sidebar or with 7; the second tab is the download history.
Four ranges, chosen beside the heading: 24 hours, 7 days, 30 days and 1 year. Every figure on the page follows the one you pick, except the all-time tile.
| Tile | What it counts |
|---|---|
| Completed | Transfers in the range |
| Failed | Final or blocked |
| Retries | Attempts scheduled again |
| Transferred | Data in the range |
| Turnaround | Mean time from a transfer being created to it completing |
| All time | Total data, with the number of transfers beside it — never thinned |
Turnaround is easy to misread. It measures from creation to completion, so it includes the time a transfer spent queued, waiting out a retry, waiting on a captcha or held back by a bandwidth schedule. It is not a throughput measurement.
All time is never folded or deleted by the retention settings — only by clearing the statistics yourself (below) — so it still answers "how much altogether" after the detailed history has gone.
Data transferred is drawn as bars, per hour on the short range and per day on the longer ones, with the largest bar's value named in the description. An empty range says Nothing was transferred in this range.
Below it, the same range broken down two ways:
- By kind — HTTP, Usenet, media, gallery, stream recording, torrent, FTP, SFTP, and anything a transfer plugin carries.
- By provider — the provider an account belonged to, or no account where the transfer used none.
Each table gives Done, Failed, Retried and Data per row. Both key columns show the service's own identifier rather than a translated name, so a row reads the same in every language and in the metrics below.
A provider is the only thing identifying a transfer here. These figures carry no file name, no address, no host and no account label — nothing anybody typed — which is also what makes them safe to expose to a monitoring system.
When Usenet servers are set up, a table lists each of them with what it delivered today (since midnight UTC), over the last 7, 30 and 365 days, and in total, and its quota: used and limit, and used up with the action that then applies. It follows no range — every column is its own.
The figures are counted as the articles arrive and written every ten seconds, so a running download shows up in them within seconds; a crash loses at most those ten seconds. They count what the server sent, yEnc-encoded: one to three per cent more than the files, plus a little per article, and an article fetched again counts again. Together, the servers of one download come to its size plus that overhead. Setting a quota is described under Usenet.
Every completion, retry and final failure is counted together with the download's change of state, so the statistics and the queue never disagree. The figures are kept per hour, download kind and provider, without sampling.
Two settings under Settings → System → Logs & retention, in the Transfer statistics card:
- Keep hourly figures — days before hourly figures are added into daily ones.
- Retention — days the daily figures are kept before being deleted.
So the recent past keeps fine detail and the longer one a coarser record. The defaults and the permitted ranges are in Defaults and limits. The all-time totals are never touched by either setting.
Settings → System → Logs & retention → Transfer statistics → Clear empties the statistics, the all-time totals and the traffic per Usenet server among them; a server's quota figure stays. The dialog names how many rows will go and confirms that the service log, the audit log, downloads, packages and settings stay. It cannot be undone. The metrics counters below start from zero afterwards. See Diagnostics and maintenance.
The card at the foot of the page names the address of the service's own metrics, in the
Prometheus text format: /api/v1/metrics on whatever address you reached the interface on.
It needs an area of its own. A token holding Metrics reaches that one route and nothing else — not the queue, not these statistics, not the MCP endpoint — and a read-only API token does not reach it. Create one under Settings → Clients & API → API & MCP with the Metrics area ticked.
What it exposes is the operational picture rather than this page: queue depth by kind and state, how long waiting downloads have waited, the current rate, active runners, completed and failed transfers, bytes, retries and turnaround by kind and provider, accounts by provider, blocked hosts, and free, total and blocked space per storage root. The counters never go backwards across a restart or a retention sweep; only clearing the statistics by hand resets them.
How to run Prometheus beside the container, with the token in a file, is in Docker and NAS.
A ready Grafana dashboard for these metrics is in the repository:
packaging/grafana/rdownloader-dashboard.json.
Import it in Grafana (Dashboards → New → Import) and pick your Prometheus data source; it shows
version and uptime, the queue by state, rates, transfers ended, throughput and retries per
provider, mean turnaround, queue wait, accounts and free space per storage root, with a choice of
data source and instance at the top.
- The download queue — the live figures, and the queue these totals describe
- Defaults and limits — the retention defaults
- Diagnostics and maintenance — the log, the audit log and the diagnostic bundle
- Accounts, sessions and permissions — API tokens and the areas they carry