I came back to a long-lived server this week to find /var/log/journal sitting at several gigabytes, and spent a minute being annoyed at systemd before remembering that this is entirely the configured behaviour. With persistent journals enabled, journald will use up to 10% of the filesystem it lives on before it starts rotating. On a roomy disk that is a lot of logs you never asked to keep.
First, see the actual number rather than guessing:
journalctl --disk-usage
If you want it reclaimed immediately, vacuum it. You can trim by size or by age, and neither touches the live journal, only the rotated history:
journalctl --vacuum-size=500M
journalctl --vacuum-time=2weeks
That fixes today. To stop it coming back, set the cap properly in /etc/systemd/journald.conf. The three knobs worth knowing are SystemMaxUse for the hard size limit, SystemKeepFree for the headroom it must leave on a shared partition, and MaxRetentionSec for the age ceiling:
[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=1month
Restart with systemctl restart systemd-journald and the limits apply on the next rotation. The journal was never leaking; it was just enforcing a generous default on a machine that had been up long enough for "generous" to mean "most of /var".
One detail catches people out. If /var/log/journal does not exist, the journal is volatile, lives in /run, and disappears on reboot, never touching your disk. So if you ever "fix" a disk-usage problem by deleting that directory, you have also quietly turned off persistent logging, and you will wonder where your history went after the next restart. Decide on purpose whether you want persistence, then create or remove the directory accordingly.
It is also worth pointing the same lens at anything else writing to /var. The journal is usually the most visible offender because it announces itself in journalctl --disk-usage, but a chatty application log with no rotation will fill a partition just as happily and with far less ceremony. Cap the journal, then go and check du -sh /var/log/* for the next thing waiting to surprise you.
Pin the numbers to what you actually want and it stops being a thing you think about, which is the only outcome any logging config should aim for.