The History tab remembers what was downloaded: every package that completed or failed for good, with its name, kind, category, destination, size, the addresses its files came from, how it ended and when. An entry stays after the package left the download list — removed by hand, cleaned up by Remove finished packages automatically, or deleted by an automation tool — so "what was that file I fetched last month, and from where?" still has an answer.

It is the second tab of Statistics & history: open that page from the sidebar or with 7 and choose History, or press h to land on the tab directly. The tab is part of the address (/stats?tab=history), so a bookmark, a reload and the browser's back button keep it; an old bookmark to /history still arrives here. Refresh beside the introduction reloads the list.

The package…	Entry
finished and its post-processing succeeded (or it had none)	Completed
finished downloading, but repair, unpacking, a scan or the upload failed	Failed, with the code of the step that failed
had every file fail, none finished	Failed, with the download's own error code
is waiting for a retry	none yet — only an outcome that is final counts

A package that is retried and ends again keeps one entry, showing its latest outcome. The entry is written in the same database step as the package's outcome, so a restart neither loses one nor writes it twice.

No secrets. The addresses are stored the way the logs show them: a user name and password in the address, a token=, key=, signature or similar query value, and anything after # are removed or masked. Archive passwords are never stored in the history.

The search field matches part of the name or of a source address, without regard to case. Beside it:

• Outcome — completed or failed.
• Type — HTTP, Usenet, torrent, media, gallery, recording, FTP, SFTP, plugin transfer or object storage.
• Period — the last 24 hours, 7, 30 or 365 days.

Press Apply filters. The list shows the newest first, 50 at a time; Load more fetches the next ones. The counter beside the title says how many entries match.

The chevron at the end of a row opens the details: category, destination folder, when the package was added, and every source address.

Add again puts the entry's source addresses back into the LinkGrabber as one package under the entry's name. From there it is checked online and reviewed like any pasted link — the domain blocklist and the routing rules apply. A toast offers the way to the LinkGrabber.

An entry whose files had no address of their own — an imported NZB — has nothing to add again, and its button is disabled. A link whose token was masked arrives without it; the online check then shows whether the hoster still accepts it.

Settings → System → Logs & retention → Download history retention sets how many entries are kept (100–100,000, default 10,000) and for how many days (1–3,650, default 365). Whichever runs out first applies; the oldest entries go first, within a minute of the change.

Clear history beside the list removes every entry after a confirmation that names how many. The download list, the files, the statistics and the logs are not touched. The clear is recorded in the audit log.

The SABnzbd-compatible API reports the history too: packages still in the list and those that already left it. When Sonarr, Radarr or a similar tool deletes an item from its history, the item disappears from the tool's view, while the History tab keeps it.

Over the REST API the history is GET /api/v1/history (with q, outcome, kind, from, to, limit and offset); over MCP the tools are list_download_history, readd_history_entry and clear_download_history.

• The download queue — where packages live until they finish
• The LinkGrabber — where an entry goes when it is added again
• Statistics — the figures over time, which the history does not replace
• Defaults and limits