Windows Updates: statistics
Read the share served from the cache, disk usage against the limit, and the module counters.
Two tabs give figures.
Super-cache statistics answers how much the cache saves.
Statistics shows the raw counters of the whole module, decision-source mode included.
Super-cache statistics
Open Windows Update, then the Super-cache statistics tab.
Choose the period in the header: 24h, 7d or 30d.
The period changes the traffic chart only.
Disk usage against the size limit, and the share served from the cache.
Maximum size / used size
The ring compares the space in use with the storage limit.
| Part | Content |
|---|---|
| Super-cache files | Files stored by the super-cache. Rotation can remove them. |
| Administrator catalog files | Approved content objects of the decision-source mode. Rotation never removes them. |
| Other files | Databases and leftover temporary files in the storage directory. |
| Reserved for downloads in progress | Space held for files being downloaded. |
| Free within the size limit | What new files can still use. |
Without a limit, the ring uses the disk size instead.
Disk free space / total shows the file system that holds /home/artica/windows-update.
The figures are refreshed every 30 seconds at most.
Served from the cache / retrieved from the Internet
Three figures sum up the period.
- Share served from the cache: the part of the bytes delivered to computers that did not cross the Internet link.
- From the cache: the bytes the cache saved.
- Retrieved from the Internet: the bytes downloaded from Microsoft to fill the cache, plus the bytes relayed without storage.
The first computer that receives a file while Artica downloads it counts as served from the Internet.
Its bytes came from Microsoft at that moment.
The saving starts with the next computer.
The bars show the volume delivered in each hour, or each day for 7d and 30d.
The line shows the share served from the cache.
An interval with no traffic has no point on the line.
Days are UTC days.
When the period has no traffic, the tab says so instead of drawing an empty chart.
On the status card
The Microsoft super-cache card on Status shows the same figures since the update that introduced them.
Downloaded from Microsoft counts acquisitions only.
Hits / misses are lifetime totals of the module.
These counters started at zero with the version of 4 November 2026.
Older traffic is not counted in them.
Module statistics
Open the Statistics tab.
The service must be running to read the metrics and cache state.
The view refreshes every ten seconds.
Real counters and cache occupation on the test appliance before client traffic.
Transfer counters
| Display | What it measures |
|---|---|
| Incoming update requests | Update requests received by Artica, including refused requests. |
| HTTP body bytes sent to clients | Response bodies written to clients. This includes protocol responses and errors. |
| HTTP body bytes received from source | Bodies read from the upstream source, including partial or failed transfers. |
| Content bytes served locally | Content served from an existing cached object or after a shared acquisition. |
| Relays caused by storage limits | Requests relayed without new storage because quota or free space was insufficient. |
These counters measure HTTP bodies.
They exclude TCP, TLS and HTTP header overhead.
When an outgoing proxy serves content from its own cache, source bytes are not a measurement of physical Internet traffic.
A downloaded byte count does not prove an installed update.
Cache occupation
The cache section shows the storage allowance, stored file bytes, reserved bytes and capacity for new objects.
The relay indicator becomes active when additional content cannot be stored.
Existing files remain available locally in relay mode.
History and persistence
Metrics are stored in a local bbolt database.
Lifetime counters survive service restarts.
The retention setting applies to minute samples, not the lifetime totals.
Missing periods in the chart are left as gaps rather than presented as confirmed zero traffic.
Request counts are recorded at entry.
Transfer bytes are recorded when the response finishes or closes.
A process failure can lose the byte count of an unfinished transfer.
Health and metric checks do not inflate update request counts.
Read the figures together
- Client bytes rising with local bytes usually indicate cache reuse.
- Source bytes rising with little local reuse can indicate first downloads, expired cacheability or repeated relays.
- Relay counts rising with a full cache indicate that more disk allowance or free space is needed.
- Metric write errors require investigation before the counters are used for reporting.
Related: Microsoft super-cache, storage limits and troubleshooting.