# Limit Linux system journal growth while keeping useful incident logs

When a service logs the same error for hours, its journal can consume space you need for application data. Set a measured retention policy after you preserve useful evidence and investigate the repeated error. Deleting logs alone will not repair the producer.

## Confirm what uses the space

These commands apply to a systemd-based Linux VPS you administer. They require sudo for system-wide inspection and configuration. They are not game console commands, and they do not manage the separate logs inside Docker, Nginx or an application's own directory.

```
sudo journalctl --disk-usage
df -hT /var/log
sudo journalctl --since "1 hour ago" -p warning --no-pager
```

Keep the affected filesystem and a few error timestamps in your notes. Use our [Linux disk-space guide](https://help.cloudexa-hosting.com/books/vps-dedicated-servers/page/find-what-is-using-disk-space-on-a-linux-vps) if the journal accounts for only a small part of the usage. An application log file needs that application's rotation policy; changing journald will not rotate every file under /var/log.

## Preserve evidence before reducing history

Save the relevant incident window outside the filesystem you are trying to relieve. Redact secrets before sharing it. Keep enough time before the failure to show the lead-up as well as the error. Ask your team about audit or contractual retention requirements before shortening history.

Review existing configuration and drop-ins under /etc/systemd/journald.conf.d/. Record whether the journal lives persistently under /var/log/journal or at runtime under /run/log/journal. A limit for one location does not automatically describe the other.

## Choose a bounded policy

For a persistent journal, create a small dedicated drop-in with your editor rather than rewriting the distribution's whole configuration. Preserve any file already at the chosen path. An illustrative policy in /etc/systemd/journald.conf.d/60-local-retention.conf is:

```
[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=14day
```

These values are examples, not a recommendation for every disk. Leave headroom for your workload and choose how much investigation history you need. [The journald reference](https://www.freedesktop.org/software/systemd/man/254/journald%40.conf.html) explains these controls. Size pressure can remove old history before the time limit; fourteen days is a maximum age here, not a promise to retain fourteen days of entries.

Apply the configuration during a suitable window using sudo systemctl restart systemd-journald. Check its status and fresh messages afterward. Do not stop journald and leave it stopped, and do not remove its active files by hand. For runtime journals, review the documented RuntimeMaxUse and RuntimeKeepFree settings instead of copying persistent-storage values without checking.

## Reclaim old history only if you intend to

[journalctl vacuuming](https://www.freedesktop.org/software/systemd/man/254/journalctl.html) removes archived journal files. After preserving evidence, sudo journalctl --rotate --vacuum-time=14days can rotate active files and remove eligible old archives. This deletes history and cannot be undone by restoring the configuration. Recheck disk usage afterward; active files and other logs still use space.

Confirm new SSH and application events still appear, then investigate the noisy service with its owner. To reverse the policy, restore the previous drop-in or remove only the file you added, and restart journald. This restores the configuration, not already removed records. Send support the measured usage, service name and redacted error sample using our [support-ticket checklist](https://help.cloudexa-hosting.com/books/getting-started/page/open-a-support-ticket) if the growth returns.