--- title: "How to analyze Linux VPS logs with journalctl and grep | StreetHosting" description: "Filter VPS logs by service, date and priority with journalctl, know what to look for in auth.log, syslog and Nginx, and keep log size in check with logrotate." url: "https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs" type: "page" language: "en-US" --- VPS · 9 min · Intermediate Published on Sep 28, 2026 · Updated on Sep 28, 2026 # Finding the cause of an error in your VPS logs: journalctl, /var/log and logrotate Almost every server problem leaves a trace in some log. See where each record lives on Ubuntu, how to slice by service, time and severity, and how to keep logs from filling the disk. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Linux administration](https://streethosting.com.br/en/guides/topics/linux) [Errors and diagnostics](https://streethosting.com.br/en/guides/topics/troubleshooting) [Monitoring and alerts](https://streethosting.com.br/en/guides/topics/monitoring) [Network, DNS and domains](https://streethosting.com.br/en/guides/topics/networking) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=How%20to%20analyze%20Linux%20VPS%20logs%20with%20journalctl%20and%20grep&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs "Share on LinkedIn") [](https://wa.me/?text=How%20to%20analyze%20Linux%20VPS%20logs%20with%20journalctl%20and%20grep%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fanalyze-linux-vps-logs "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs.md) In this guide 7 sections * [Where Linux keeps its logs](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#onde-ficam) * [journalctl: service, date and priority](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#journalctl) * [The /var/log files that matter](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#var-log) * [A roadmap for investigating an error](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#roteiro-erro) * [Real cases: SSH, Nginx and memory](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#casos-praticos) * [Logrotate and the journal size limit](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#logrotate) * [When logs point to a resource shortage](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#dimensionamento) Quick answer To **analyze logs on a Linux VPS**, start with journalctl: `journalctl -u nome-do-servico` filters by service, `--since` and `--until` narrow the time window, `-p err` shows only errors and `-b` limits output to the current boot. Round it out with the files in /var/log, such as auth.log for SSH access, syslog for the system and the Nginx logs, and set up logrotate so the logs do not fill the disk. ## Where Linux keeps its logs[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#onde-ficam) On Ubuntu, logs live in two places at once. journald, part of systemd, receives the output of every service plus the kernel messages and stores it all in an indexed binary format that you read with journalctl. rsyslog reads the same stream and writes text files to /var/log, such as syslog and auth.log. Some programs, like Nginx and databases, also write their own files that never go through the journal. On Ubuntu 24.04, both mechanisms come enabled. On Debian 12, rsyslog is not installed by default, so syslog and auth.log may not even exist; there, journalctl is the way to go for almost everything. | Where | What it records | How to read it | | ------------------------ | ------------------------------------------------------------- | --------------------------- | | Journal (journalctl) | Output of every systemd service and kernel messages | journalctl with filters | | /var/log/syslog | General messages from the system and its services | less, grep and tail | | /var/log/auth.log | SSH logins, sudo usage and authentication failures | grep for Failed or Accepted | | /var/log/kern.log | Kernel messages: disk, network and the OOM killer | grep for error or oom | | /var/log/nginx/ | access.log with every request and error.log with the failures | tail, awk and grep | | /var/log/apt/history.log | What was installed, updated or removed, and when | less | | /var/log/fail2ban.log | IPs banned and unbanned by Fail2ban | grep for Ban | | /var/log/ufw.log | Packets blocked by the firewall, if UFW logging is on | grep for BLOCK | Files ending in .1 or .gz are older versions that have already been rotated. The compressed ones can be read without decompressing, with zgrep and zless. Before any investigation, check that the VPS clock is in the right time zone. A log in UTC compared against the Brasília time on your phone yields three hours of confusion, and in an investigation the timestamp is everything. The fix takes one command and is covered in [VPS time zone and language for Brazil](https://streethosting.com.br/en/guides/vps/set-vps-timezone-brazil). ## journalctl: service, date and priority[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#journalctl) journalctl with no filter dumps everything from the oldest record onward, which helps nobody. Its strength is in combining filters: `# by service (systemd unit name) journalctl -u nginx journalctl -u ssh # follow in real time, like tail -f journalctl -u minha-app -f # last 100 lines, no pager journalctl -u minha-app -n 100 --no-pager # by time window journalctl --since "2026-09-28 08:00" --until "2026-09-28 09:30" journalctl --since "30 min ago" journalctl -u nginx --since yesterday --until today # errors only, plus anything more severe journalctl -p err -b # current boot, previous boot and the list of boots journalctl -b journalctl -b -1 journalctl --list-boots # kernel messages journalctl -k` The `-u` filter takes the same name you pass to systemctl status. On Ubuntu, the SSH service is called ssh. `-p err` shows the given priority and everything more severe (crit, alert and emerg), and it also accepts warning when you want to see warnings. `-b -1` shows the previous boot and is the most useful filter after an unexpected restart, because it brings up the last lines before the machine went down. If `--list-boots` shows only the current boot, the journal is being kept in memory only and is lost on every restart. Recent Ubuntu releases usually make it persistent already, but if yours does not, create the folder and restart journald: `sudo mkdir -p /var/log/journal sudo systemctl restart systemd-journald` Three more options round out the toolkit. `-g` searches for a pattern inside the messages, such as `journalctl -u minha-app -g "timeout|refused"`. `-o short-iso` switches the date to year, month and day format, which sorts and compares better. And `--disk-usage` shows how much space the journal takes up. A typical investigation query puts it all together: `journalctl -u minha-app -p warning --since today -o short-iso`. ## The /var/log files that matter[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#var-log) Text files have one advantage: they work with the usual tools. Four commands handle almost everything: `sudo tail -f /var/log/syslog sudo grep -i "error" /var/log/syslog | tail -n 50 sudo zgrep "Failed password" /var/log/auth.log* sudo less +G /var/log/nginx/error.log` tail -f follows the file in real time. grep -i ignores case. zgrep also searches the rotated, compressed files, so the trailing asterisk covers the last few weeks in one go. less +G opens the file already at the end, where the newest lines are; inside it, Shift and F switch to following like tail does. auth.log is the access diary of the VPS. Lines with Accepted publickey or Accepted password are successful logins. Failed password and Invalid user are failed attempts. A VPS with a public IP gets thousands of these attempts a day from bots that sweep the internet; it is normal noise and the reason to use SSH keys only and [Fail2ban to protect SSH](https://streethosting.com.br/en/guides/vps/fail2ban-ssh-vps-setup). /var/log/apt/history.log answers a question that comes up in every investigation: what changed yesterday? It shows the date, the command and the packages of every install or update. Many cases of "it started failing out of nowhere" line up with an automatic update, which is also recorded in `/var/log/unattended-upgrades/`. ## A roadmap for investigating an error[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#roteiro-erro) When something broke and you do not know where to start, go from the general to the specific: 1. `systemctl --failed` lists the units that failed. 2. `systemctl status nome` shows the state, the exit code and the last log lines of the service. 3. `journalctl -u nome -b -p warning` brings up the warnings and errors of the service since boot. 4. Find the time of the first error and open the window around it across the whole system, with no service filter: `journalctl --since "09:12" --until "09:20"`. 5. Cross-check with the logs of the application itself, of Nginx and of the database for the same minute. Step four is the one that saves the most time. The error in your service is almost always a consequence of something else: the application crashed because the database refused the connection, the database refused because it restarted, and it restarted because the kernel killed it for running out of memory. Looking at the whole system in that window, the chain shows up in chronological order. Learn to read the exit code in systemctl status. status=9/KILL means the process was killed forcibly, often by the OOM killer. status=203/EXEC means systemd could not execute the binary, because of a wrong path or a missing permission. status=1/FAILURE is the application itself exiting with an error, and the reason is in the preceding log lines. ## Real cases: SSH, Nginx and memory[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#casos-praticos) ### SSH login attempts[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#caso-ssh) `# how many failures today sudo journalctl -u ssh --since today | grep -c "Failed password" # IPs with the most attempts sudo grep "Failed password" /var/log/auth.log | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn | head # successful logins sudo grep "Accepted" /var/log/auth.log` The last list is the one that matters. A failed login is noise; an Accepted coming from an IP you do not recognize is an incident, and the first response is to rotate keys, review the users with access and check what was done from that session. ### 5xx errors and IPs in Nginx[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#caso-nginx) `# requests with a 5xx status in the current log sudo awk '$9 ~ /^5/' /var/log/nginx/access.log | tail -n 20 # IPs making the most requests sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head # paths generating the most 404s sudo awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head # what Nginx says about the application behind it sudo grep -i "upstream" /var/log/nginx/error.log | tail -n 20` In the default Nginx format, field 9 is the status code and field 7 is the requested path. A 502 Bad Gateway almost always shows up in error.log as `connect() failed (111: Connection refused) while connecting to upstream`: Nginx is up, but the application behind it is not accepting connections. The next step is the journalctl of the application. A single IP with thousands of requests per minute can be a misbehaving search bot, a scraper or the start of an application-layer attack. How to tell a legitimate spike from an attack is covered in [how to identify a DDoS attack on your server](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server). ### Processes killed for running out of memory[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#caso-memoria) `sudo journalctl -k -b | grep -i -E "out of memory|killed process" sudo journalctl -k -b -1 | grep -i oom` When memory runs out, the kernel picks a process, usually the largest, and kills it. The Killed process line gives its name and PID. If it shows up often, restarting the service alone will not help: you need to reduce consumption, set limits or add RAM. ## Logrotate and the journal size limit[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#logrotate) A log that only grows eventually eats the disk. logrotate runs once a day, triggered by a systemd timer, renames the files, compresses the old ones and deletes those past the limit. Packages like Nginx already install their own rule in /etc/logrotate.d/. For the logs of your application, create a file: `# /etc/logrotate.d/minha-app /var/log/minha-app/*.log { daily rotate 14 compress delaycompress missingok notifempty copytruncate }` With daily and rotate 14, you keep two weeks of history. compress gzips the old ones and delaycompress leaves the most recently rotated file uncompressed, to make it easier to read. copytruncate copies the file and empties the original in place, which works for applications that do not reopen their log on their own; the price is losing the few lines written during the copy. If the application knows how to reopen the file on a signal, prefer a postrotate block with the reload. Test before you trust it: `sudo logrotate -d /etc/logrotate.d/minha-app # dry run, changes nothing sudo logrotate -f /etc/logrotate.d/minha-app # force a rotation now` The journal has a limit of its own: by default, up to 10% of the filesystem, capped at 4 GB. On a 20 GB VPS, that can reach 2 GB of journal alone. To set a lower limit: `journalctl --disk-usage sudo journalctl --vacuum-size=300M # permanent limit in /etc/systemd/journald.conf [Journal] SystemMaxUse=300M sudo systemctl restart systemd-journald` Do not rm a log that a process is still writing to. The file disappears from the listing, but the space is only freed when the process closes the file. To empty it without that problem, use `sudo truncate -s 0 /caminho/arquivo.log`. The full case, with the lsof diagnosis, is in [finding out what is using disk space on your VPS](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps). ## When logs point to a resource shortage[](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#dimensionamento) Logs tell you what broke; metrics tell you how the machine got there. If the logs keep repeating the same pattern, such as processes killed by the OOM killer, database timeouts at every peak hour or No space left on device, the fix is not in the log: the VPS has become too small for the load. To catch those signals before they turn into downtime, pair the logs with resource alerts, as described in [how to monitor a VPS 24 hours a day](https://streethosting.com.br/en/guides/vps/monitor-vps-24-7). When the conclusion is a resource shortage, upgrading through the control panel increases memory, vCPU and disk at once, charges only the prorated difference for the cycle and requires a VM restart. StreetHosting VPS run on KVM, with NVMe, root access and Anti-DDoS, in the São Paulo datacenter. The Ryzen 9 9950X line goes from R$ 40.00 (1 vCPU, 2 GB, 20 GB NVMe) to R$ 846.00 (14 vCPU, 64 GB, 640 GB) and the Xeon line goes from R$ 26.00 (2 vCPU, 2 GB, 20 GB) to R$ 553.00 (24 vCPU, 64 GB, 640 GB). At every tier the disk grows along with the memory, which leaves room for logs and the journal without squeezing. See the options on the [VPS page](https://streethosting.com.br/en/vps). In this guide * [Where Linux keeps its logs](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#onde-ficam) * [journalctl: service, date and priority](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#journalctl) * [The /var/log files that matter](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#var-log) * [A roadmap for investigating an error](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#roteiro-erro) * [Real cases: SSH, Nginx and memory](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#casos-praticos) * [Logrotate and the journal size limit](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#logrotate) * [When logs point to a resource shortage](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs#dimensionamento) ## Frequently asked questions How do I view a service's log on Linux? Use journalctl -u followed by the unit name, such as journalctl -u nginx. Add -f to follow in real time, -n 100 to see only the last lines and -b to limit it to the current boot. How do I filter journalctl by date and time? Use --since and --until with the date and time in quotes. For today, the time alone is enough, such as --since 08:00 --until 09:30, and natural expressions like yesterday, today and 1 hour ago also work, quoted when they contain a space. Where is the log of SSH login attempts? On Ubuntu, in /var/log/auth.log, and also in the journal with journalctl -u ssh. Lines with Failed password and Invalid user are failed attempts. Lines with Accepted show the logins that succeeded, and that is the list that deserves the most attention. Why does journalctl show nothing from before the last reboot? Because the journal is being kept in memory only. Create the /var/log/journal folder and restart the journald service. From then on, previous boots are kept and journalctl -b -1 shows what happened before the crash. Can I delete the files in /var/log? Old files that have already been rotated, ending in .gz or numbered, can be removed. Do not rm a log that is in use, because the process keeps writing to the deleted file and the space never comes back; empty it with truncate -s 0 and let logrotate handle the rest. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) ## Related guides [VPS Intermediate How to set up Fail2Ban on a VPS: SSH, Nginx and repeat offenders Fail2Ban reads your logs, spots the IPs that fail too often and bans them in the firewall. Learn how to set it up on Ubuntu 24.04, where the package defaults change how jails behave, and how to manage bans day to day. 8 min Read guide](https://streethosting.com.br/en/guides/vps/fail2ban-ssh-vps-setup) [VPS Beginner What is taking up disk space on your VPS: how to find and free it A full disk takes down databases, stalls updates and makes applications fail without a clear error message. Here is how to find the culprit in a few commands and what you can delete without breaking anything. 9 min Read guide](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps) [VPS Intermediate How to monitor a VPS 24/7: metrics, alerts and uptime An uptime monitor on its own will not tell you the disk is filling up or that backups stopped three weeks ago. Here is how to combine availability, resources, scheduled jobs and alerts into a routine that works day and night. 10 min Read guide](https://streethosting.com.br/en/guides/vps/monitor-vps-24-7) [← Back to the Guide Center](https://streethosting.com.br/en/guides)