journalctl explained with examples: finding errors from a Linux app
Published on 2026-10-26 by frfrand
Search service logs by unit, priority, and date with journalctl
When an app crashes at three in the morning, the question isn't "what command restarts everything?". It's "what happened right before?". journalctl lets you query service logs with time, unit, and priority filters.
I'll show you where the problem is, how to check it without guessing, and what I'd do in an application that actually has users. You don't need to memorize an entire manual to fix a specific failure.
What journalctl means in practice
The systemd journal stores events from compatible applications and services. It can be filtered by unit (-u), boot (-b), priority (-p), and time windows. Retention depends on configuration and available space.
A clarification before touching the server: if the project is already in production, save the state you found and check which user and machine you'll run the commands on. Working as root without need and changing several things at once makes it harder to find the cause of an error.
Useful commands to get started
sudo journalctl -u miapp -n 100 --no-pager
sudo journalctl -u miapp --since '2026-10-26 09:00' --until '2026-10-26 10:00'
sudo journalctl -b -p err --no-pager
sudo journalctl -u miapp -f
sudo journalctl --disk-usagePaths, unit names, and domains are examples. Adapt them to your service. If a command requires administrator permissions, check what changes and why. Diagnostic queries should come before modifications.
Step by step, with checks
- Identify the real name of the unit running the application.
- Find the failure time and narrow it down with
--sinceand--until. - Follow the oldest error in the chain first, not the last symptom.
- If there are several services, compare timestamps from Nginx, API, and worker.
- Define retention and avoid logging passwords or personal data.
After each step, verify an observable result: a status, a file, an HTTP response, or a log entry. If you find an unexpected message, save it for investigation instead of hiding it with repeated restarts.
Real example: an application that needs maintenance
A reservation returns 500 only when the user adds a long note. The logs show a validation error before any connection to PostgreSQL: the problem was not the VPS nor the proxy.
At the end, test the full path: enter through the domain, call the API, write a test data, and verify that the information remains after a controlled restart. A server that "starts" is not always an application that works.
Errors worth avoiding
If the application stores its logs only in its own file, journalctl might not show all the information. Confirm where stdout, stderr, and structured logs are written.
It is also important that credentials do not end up in terminal history, logs, shared files, or screenshots. For users and services, use minimal permissions and document who can revoke access.
How ArduMaker fits into this scenario
At ArduMaker, log querying by VPS and process helps investigate without blindly restarting. Use that evidence to create incidents with clear reproduction steps.
ArduMaker can help you manage VPSs, deploy repositories, and work with services, databases, and domains from the same platform. It does not replace what we just explained about Linux: precisely for that reason, it is worth understanding diagnostics and having a way to repeat them.
When it is worth automating
If the task repeats, first document the manual procedure and its checks. Then consider a script or a scheduled task with visible errors, logs, and limited permissions. Do not automate a command that you do not yet know how to recover when it goes wrong.
Frequently asked questions
Can I try it without affecting customers? In many cases, yes: a staging VPS or a separate test service allows you to validate the configuration before changing production.
How do I know it went well? Check logs and a functional operation, not just that the command ended with exit code zero.
When do I need more resources? When metrics indicate CPU, RAM, disk, or connection saturation. A configuration failure is rarely fixed by hiring more memory.
References
In one sentence: first understand the error, then change one concrete thing and check its effect. That discipline saves you many hours of support.