Calculate systemd journal disk usage against SystemMaxUse and runtime journal limits.
journald continuously trims its own storage to stay within the SystemMaxUse ceiling configured in journald.conf, rotating out the oldest entries first once that cap is reached — regardless of how long an administrator might want logs retained. This means the actual disk usage is the smaller of the desired usage (log generation rate multiplied by the intended retention period) and the configured cap: if the cap is smaller than the desired usage, the effective retention window shrinks silently, which is a common surprise when diagnosing 'why did my logs from last week disappear' issues.
Actual journal disk usage
actual_usage = min(log_rate × retention_days, SystemMaxUse)
journald automatically vacuums (deletes) the oldest journal entries to make room for new ones, keeping total usage at or below the configured cap — it does not fail or block logging, but old history is silently lost once the space limit is reached.
If unset, journald defaults to using up to 10% of the filesystem it is stored on (typically /var/log/journal), with additional built-in limits like leaving at least 15% of the filesystem free — check journalctl --disk-usage and man journald.conf for the exact defaults on your distribution.
Forward logs to a centralized log aggregator (rsyslog, Loki, Elasticsearch, a SIEM) via journald's forwarding options or a log shipper, so long-term retention lives on remote storage while the local journal stays small and fast to query.