Two mechanisms doing different jobs. One is a policy you choose. The other is what keeps Loghound running on a small plan instead of switching your own dashboard off.
Figure 1 — the two mechanisms. More disk buys more history; a small plan keeps running and simply holds less.
A number of days, defaulting to ninety. Set it under Settings; neither installer asks about it.
It is a supported setting rather than a mistake: nothing is deleted for being old, and how much you keep is then decided by the size rule alone. The two rules are independent and whichever bites first wins, which is why the panel shows them side by side on one card rather than as two separate settings.
The deletion is done by a command on a daily timer, and it is a real deletion job rather than a paragraph of documentation saying you ought to have one. To run it now:
sudo -u loghound php /opt/loghound/bin/loghound-retention
And to see what it would remove without removing it:
sudo -u loghound php /opt/loghound/bin/loghound-retention --dry-run
If the timer is not enabled, this setting does nothing at all. Running it is where the units are enabled, and the panel’s retention card previews what is past the window — but the panel itself never deletes anything.
The cutoff is computed as an explicit instant rather than handed to Solr as an expression, for two reasons: the same instant is used for both indexes so they cannot drift apart mid-run, and an absolute timestamp is what gets printed in the dry run — somebody about to delete data should see a date, not an expression. There is a floor of one day, because a rounding accident that produced half a day would delete the data the dashboard is currently showing, and there is no undo.
The daily rollup documents are kept indefinitely by default. They are aggregate counts with no per-visitor field in them, they cost a few hundred bytes each, and they are what makes long-term trends survive the deletion of the detail underneath.
An index that exceeds its disk quota is not throttled and does not merely refuse writes: the platform makes it answer every request with a refusal, reads included, until usage is back under the limit. So an unbounded Loghound would eventually fill the plan and switch its own dashboard off. Preventing that is the entire point of this mechanism.
- The trim runs before a write, at a high-water mark, and aims to come back to a target below it — so the index never reaches the quota and the blackout never triggers on disk.
- It deletes by date, never by document count: a date cutoff is one cheap operation and it leaves an answer a human understands — “you have data from this date onward” — where “the oldest N documents” would need a sort, a page and a list of identifiers.
- There is a protected recent window — a day by default — that the trim will never touch whatever the arithmetic says.
- No single step may remove more than a bounded slice of the data’s timespan, however far over quota the index is, and there is a cooldown afterwards so the index’s own merges can catch up.
An unknown plan limit, an empty index, a clock that moved, a bounds query that came back inverted, a target that would take the whole index — any one of them stops the trim. Nothing deletes without a plan limit to justify it.
Because of all this, the Storage and bandwidth view presents disk as a fact about how far back your data goes rather than as an alarm. The one thing there that is an alarm is a trim that failed while the index is genuinely near the limit — because then the blackout really is coming.
The local state database is not covered by the retention window, and that is a gap worth knowing about rather than assuming away. It holds the enrichment caches — which are keyed by address — the closed-session table, merged beacon rows and the rate-limit buckets. Cache entries expire and stop being used, but the rows remain on disk until something removes them. The purge routines exist in the code and nothing currently calls them.
If your retention posture has to cover every copy, the honest answer today is that you have to do it yourself — and that the state database is not safe to simply delete: it also holds the tailer’s byte cursor in every log file and the open-session table, so removing it makes the tailer restart each source at its current end, losing anything not yet ingested, and orphans every session that had not closed.
The other thing neither covers is upstream: Loghound can only ever see as far back as your own log files, and that window is often much shorter than you assume.