The first time I met this problem properly, a box had 40GB of logs in /var/log/journal and nobody had touched the logging config since the machine was built. Nothing was broken. The journal had simply done exactly what it was told, which is to grow until it occupies a fraction of the filesystem and then start rotating. On a big disk that fraction is a lot of gigabytes, and on a small VM it is enough to make df look alarming.
The default behaviour is the part people miss. With persistent storage enabled, journald caps itself at 10% of the filesystem the journal lives on, keeping 15% free. That is a sensible default for a fresh install and a slightly silly one once you have years of uptime and a partition you share with other things. It is not a leak. It is a policy, and the policy is just bigger than you expected.
So before reaching for rm, look at what you actually have:
journalctl --disk-usage
If you want it gone now, you can vacuum by size or by age. Both are non-destructive in the sense that they only drop old entries, not live ones:
# keep at most 500M of journal
journalctl --vacuum-size=500M
# drop anything older than two weeks
journalctl --vacuum-time=2weeks
That clears the immediate fire, but it will creep back unless you tell the daemon what you actually want. The settings live in /etc/systemd/journald.conf, and the two that matter most are SystemMaxUse and MaxRetentionSec:
[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=1month
SystemMaxUse is the hard cap on how much space the journal may use. SystemKeepFree is the amount of disk it promises to leave alone, which matters when the journal shares a partition with something that also grows. MaxRetentionSec is the age ceiling. Set the ones you care about, restart the service with systemctl restart systemd-journald, and the daemon enforces them on the next rotation.
One sharp edge worth knowing: if /var/log/journal does not exist, the journal is volatile and lives in /run, so it vanishes on reboot and never touches your disk at all. People sometimes "fix" disk usage by deleting that directory and then wonder why their logs evaporate after a restart. If you want persistence, the directory needs to be there; if you do not, that is a legitimate choice, just make it on purpose.
The wider point is that journald is not misbehaving when it fills a disk. It is doing the thing the defaults asked for, on hardware those defaults were not tuned for. Two lines of config turns it from a thing you periodically panic about into a thing you never think about again.