{"id":1118,"date":"2026-02-16T10:59:01","date_gmt":"2026-02-16T10:59:01","guid":{"rendered":"https:\/\/uptimerobot.com\/knowledge-hub\/?p=1118"},"modified":"2026-02-16T11:00:58","modified_gmt":"2026-02-16T11:00:58","slug":"journalctl-explained-how-to-view-and-analyze-systemd-logs","status":"publish","type":"post","link":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/","title":{"rendered":"Journalctl Explained: How To View And Analyze Systemd Logs"},"content":{"rendered":"\n<section class=\"wp-block-knowledge-hub-theme-quick-answer alignwide quick-answer-block  align-left\"><div class=\"quick-answer-container\"><h2 class=\"quick-answer-title\" style=\"max-width:\">TL;DR (QUICK ANSWER)<\/h2><div class=\"quick-answer-content\" style=\"max-width:\">\n<ul class=\"wp-block-list\">\n<li>Start here: <code>journalctl -u &lt;service&gt; --since \"1 hour ago\" -p err<\/code><\/li>\n\n\n\n<li>For reboot issues: <code>journalctl -b -1<\/code> (previous boot) and <code>journalctl --list-boots<\/code><\/li>\n\n\n\n<li>For precision: filter with fields like <code>_SYSTEMD_UNIT=, _PID=<\/code>, and priority (-p)<\/li>\n\n\n\n<li>For scripts: use <code>--no-pager<\/code> and <code>-o json<\/code><\/li>\n<\/ul>\n<\/div><\/div><\/section>\n\n\n\n<p>When something breaks on a Linux server, logs are the first place you look. On modern systemd-based systems, that means the systemd journal.<\/p>\n\n\n\n<p>journalctl is the command-line tool for querying logs collected by systemd-journald. It pulls together messages from services, the kernel, and user processes, then lets you filter them by time, boot session, unit, PID, priority, and structured fields.<\/p>\n\n\n\n<p>Instead of jumping between \/var\/log files and grepping through text, you can run focused queries like:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What happened during the last boot?<\/li>\n\n\n\n<li>Why did this service fail 20 minutes ago?<\/li>\n\n\n\n<li>Are these errors tied to one unit or one process?<\/li>\n<\/ul>\n\n\n\n<p>If you\u2019re working on a systemd-based distro, journalctl is usually the fastest way to get answers.<\/p>\n\n\n\n<p>We\u2019ll walk through how to view, filter, and analyse logs with journalctl, including practical commands you can use during real incidents.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Key takeaways<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>journalctl is the fastest way to query systemd logs by time, boot, unit, priority, and structured fields.<\/li>\n\n\n\n<li>Boot filtering (<code>-b, --list-boots<\/code>) is one of the quickest ways to diagnose reboot-related issues.<\/li>\n\n\n\n<li>Field-based filters like <code>_SYSTEMD_UNIT, _PID<\/code>, and <code>_BOOT_ID<\/code> reduce noise and speed up root cause analysis.<\/li>\n\n\n\n<li>Output formats like JSON make <code>journalctl<\/code> useful in automation and log pipelines, not just in a terminal.<\/li>\n<\/ul>\n\n\n\n    <div class=\"wp-block-knowledge-hub-theme-intext-sidebar ur-intext-sidebar\">\n        <div class=\"widget-img\">\n            <img decoding=\"async\" src=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/themes\/generatepress-child\/assets\/images\/img-intext-sidebar.png\" alt=\"UptimeRobot\">\n        <\/div>\n        <div class=\"widget-left\">\n            <div class=\"widget-title\">\n                <span>Downtime happens.<\/span>\n                <span class=\"text-primary\">Get notified!<\/span>\n            <\/div>\n            <div class=\"widget-text\">Join the world&#039;s leading uptime monitoring service with 3.2M+ happy users.<\/div>\n        <\/div>\n        <div class=\"widget-button\">\n            <a href=\"https:\/\/dashboard.uptimerobot.com\/sign-up?utm_source=uptimerobot&#038;utm_medium=kh&#038;utm_campaign=intext-sidebar\" class=\"button\">\n                <span>Register for FREE<\/span>\n            <\/a>\n        <\/div>\n    <\/div>\n    \n\n\n\n<h2 class=\"wp-block-heading\">How systemd journald works<\/h2>\n\n\n\n<p>Before you can use journalctl well, it helps to understand what it\u2019s querying.<\/p>\n\n\n\n<p><code>systemd-journald<\/code> is the service that collects and stores log data. Instead of writing plain text files per service, it stores log entries in a structured, binary journal.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"603\" src=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-1024x603.png\" alt=\"Linux log flow with systemd\" class=\"wp-image-1119\" srcset=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-1024x603.png 1024w, https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-300x177.png 300w, https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-768x452.png 768w, https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27.png 1080w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n<\/div>\n\n\n<h3 class=\"wp-block-heading\">Binary journal files vs. plain text logs<\/h3>\n\n\n\n<p>Traditional syslog setups write logs as text files under \/var\/log. Each line is just a formatted string.<\/p>\n\n\n\n<p>Journald stores logs in binary files located in:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>\/run\/log\/journal\/<\/code> (volatile, cleared on reboot)<\/li>\n\n\n\n<li><code>\/var\/log\/journal\/<\/code> (persistent, survives reboot)<\/li>\n<\/ul>\n\n\n\n<p>Binary storage has two major implications:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Logs are not human-readable without <code>journalctl<\/code>.<\/li>\n\n\n\n<li>Queries are much faster because entries are indexed.<\/li>\n<\/ul>\n\n\n\n<p>You are querying indexed data, not scanning raw text.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Structured metadata and indexed fields<\/h3>\n\n\n\n<p>Every journal entry is stored as a set of key-value fields.<\/p>\n\n\n\n<p>A single log event might contain:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>MESSAGE=Service started\nPRIORITY=6\n_SYSTEMD_UNIT=nginx.service\n_PID=1234\n_BOOT_ID=3e2f1c4d9a234b8ca7d2a1c9d5e4b7e1\n_UID=1000<\/code><\/pre>\n\n\n\n<p>Some fields are supplied by the service. Others are added automatically by journald.<\/p>\n\n\n\n<p>Important internal fields include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>_SYSTEMD_UNIT<\/code>: the systemd unit that generated the log<\/li>\n\n\n\n<li><code>_PID<\/code>: the process ID<\/li>\n\n\n\n<li><code>_BOOT_ID<\/code>: the unique identifier for that boot session<\/li>\n\n\n\n<li><code>_UID<\/code>: the user ID<\/li>\n\n\n\n<li><code>_COMM<\/code>: the command name<\/li>\n<\/ul>\n\n\n\n<p>Because these fields are indexed, filtering by them is fast, even on systems with large log histories.<\/p>\n\n\n\n<p>Instead of:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>grep nginx \/var\/log\/syslog<\/code><\/pre>\n\n\n\n<p>You can run:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _SYSTEMD_UNIT=nginx.service<\/code><\/pre>\n\n\n\n<p>That difference matters during incident response. Indexed filtering cuts down search time and reduces noise.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Volatile vs. persistent storage<\/h3>\n\n\n\n<p>By default, journald may store logs in memory only.<\/p>\n\n\n\n<p>If <code>\/var\/log\/journal\/<\/code> does not exist, logs are written to <code>\/run\/log\/journal\/<\/code> and disappear after reboot.<\/p>\n\n\n\n<p>To enable persistent logs:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo mkdir -p \/var\/log\/journal\nsudo systemd-tmpfiles --create --prefix \/var\/log\/journal\nsudo systemctl restart systemd-journald<\/code><\/pre>\n\n\n\n<p>On production systems, persistent storage is usually required for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Post-reboot troubleshooting<\/li>\n\n\n\n<li>Audit trails<\/li>\n\n\n\n<li>Incident reviews<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Why queries stay fast on large systems<\/h3>\n\n\n\n<p>Journald maintains indexes for common fields such as unit, PID, and boot ID.<\/p>\n\n\n\n<p>That means queries like:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service --since \"1 hour ago\"<\/code><\/pre>\n\n\n\n<p>Don\u2019t scan every log entry. They use indexed lookups.<\/p>\n\n\n\n<p>This is one of the main reasons journalctl feels faster than grepping across multiple rotated log files.<\/p>\n\n\n\n<p>Understanding this structure changes how you debug systems. You aren\u2019t searching text files, you are querying structured events.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">journalctl vs. syslog and traditional log files<\/h2>\n\n\n\n<p>Both journald and traditional syslog systems record system and application events. The difference is in how they store, structure, and query logs.<\/p>\n\n\n\n<p>On systemd-based systems, journald is the default. But many environments still use syslog daemons like <code>rsyslog<\/code> or <code>syslog-ng<\/code>, often alongside journald.<\/p>\n\n\n\n<p>Here\u2019s how they compare.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">How traditional syslog works<\/h2>\n\n\n\n<p>Syslog-based systems write logs as plain text files under \/var\/log.<\/p>\n\n\n\n<p>Examples:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>\/var\/log\/syslog<\/code> or <code>\/var\/log\/messages<\/code><\/li>\n\n\n\n<li><code>\/var\/log\/auth.log<\/code><\/li>\n\n\n\n<li><code>\/var\/log\/kern.log<\/code><\/li>\n<\/ul>\n\n\n\n<p>Each entry is just a formatted string. Searching means scanning files with tools like:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>grep<\/code><\/li>\n\n\n\n<li><code>awk<\/code><\/li>\n\n\n\n<li><code>less<\/code><\/li>\n<\/ul>\n\n\n\n<p>Rotation is handled separately via <code>logrotate<\/code>, which archives and compresses old logs.<\/p>\n\n\n\n<p>There\u2019s no built-in structure beyond whatever format the service writes.<\/p>\n\n\n\n<figure class=\"wp-block-table aligncenter\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Pros<\/strong><\/td><td><strong>Cons<\/strong><\/td><\/tr><tr><td>Plain text and easy to grep<\/td><td>No structured metadata<\/td><\/tr><tr><td>Broad compatibility<\/td><td>Slower searches on large systems<\/td><\/tr><tr><td>Mature ecosystem of shipping tools<\/td><td>Logs fragmented across files<\/td><\/tr><tr><td>Decoupled from system internals<\/td><td>Requires external rotation management<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">How journalctl differs<\/h2>\n\n\n\n<p>With journald, logs are stored as structured binary entries.<\/p>\n\n\n\n<p>Each log entry includes indexed metadata such as:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>_SYSTEMD_UNIT<\/code><\/li>\n\n\n\n<li><code>_PID<\/code><\/li>\n\n\n\n<li><code>_BOOT_ID<\/code><\/li>\n\n\n\n<li><code>_UID<\/code><\/li>\n\n\n\n<li><code>PRIORITY<\/code><\/li>\n<\/ul>\n\n\n\n<p>Instead of searching across multiple files, you query fields directly:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service\njournalctl -p err --since \"1 hour ago\"<\/code><\/pre>\n\n\n\n<p>Because journald indexes common fields, filtering is significantly faster on large systems.<\/p>\n\n\n\n<figure class=\"wp-block-table aligncenter\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Pros<\/strong><\/td><td><strong>Cons<\/strong><\/td><\/tr><tr><td>Fast indexed queries<\/td><td>Binary format requires journalctl<\/td><\/tr><tr><td>Structured filtering by unit, PID, boot ID<\/td><td>Not available on non-systemd systems<\/td><\/tr><tr><td>Unified view of kernel and services<\/td><td>Some legacy tooling expects text logs<\/td><\/tr><tr><td>Built-in retention and disk controls<\/td><td>Misconfiguration can lead to disk growth<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Direct comparison<\/h2>\n\n\n\n<figure class=\"wp-block-table aligncenter\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Category<\/strong><\/td><td><strong>journalctl (journald)<\/strong><\/td><td><strong>Syslog \/ traditional logs<\/strong><\/td><\/tr><tr><td>Storage format<\/td><td>Binary journal files<\/td><td>Plain text files<\/td><\/tr><tr><td>Metadata<\/td><td>Structured and indexed fields<\/td><td>Mostly unstructured message text<\/td><\/tr><tr><td>Query speed<\/td><td>Fast field-based lookups<\/td><td>File scanning with grep<\/td><\/tr><tr><td>Cross-service filtering<\/td><td>Single query across units and kernel<\/td><td>Manual across multiple log files<\/td><\/tr><tr><td>Log rotation<\/td><td>Built-in retention controls<\/td><td>Managed separately with logrotate<\/td><\/tr><tr><td>Human readability<\/td><td>Requires journalctl<\/td><td>Directly readable<\/td><\/tr><tr><td>Portability<\/td><td>Requires systemd<\/td><td>Works across init systems<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">When teams use both<\/h3>\n\n\n\n<p>In many production environments:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>journald collects logs locally.<\/li>\n\n\n\n<li>A syslog daemon reads from the journal.<\/li>\n\n\n\n<li>Logs are forwarded to a centralized stack (ELK, Loki, Splunk, Graylog).<\/li>\n<\/ul>\n\n\n\n<p>That setup keeps fast local debugging with journalctl while supporting long-term aggregation and analysis.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Basic journalctl commands you should know<\/h2>\n\n\n\n<p>Before you get into advanced filtering, you should be comfortable with a few core commands. These cover 80% of day-to-day troubleshooting.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Viewing all logs<\/h3>\n\n\n\n<p>To display the entire journal:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl<\/code><\/pre>\n\n\n\n<p>This shows logs in chronological order, oldest first.<\/p>\n\n\n\n<p>On busy systems, that\u2019s usually too much output. But it\u2019s useful when you need a complete timeline.<\/p>\n\n\n\n<p>If you want newest entries first:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -r<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Paging and navigation<\/h3>\n\n\n\n<p>By default, journalctl pipes output into a pager (usually less).<\/p>\n\n\n\n<p>Inside the pager, you can:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Space to scroll down<\/li>\n\n\n\n<li>Use b to scroll up<\/li>\n\n\n\n<li>Use \/ to search<\/li>\n\n\n\n<li>Press q to quit<\/li>\n<\/ul>\n\n\n\n<p>If you\u2019re scripting or don\u2019t want paging:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --no-pager<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Limiting output<\/h3>\n\n\n\n<p>To show only the last 100 lines:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -n 100<\/code><\/pre>\n\n\n\n<p>To show the last 50 lines for a service:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service -n 50<\/code><\/pre>\n\n\n\n<p>This is one of the fastest ways to check recent failures.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Following logs in real time<\/h3>\n\n\n\n<p>To stream logs as they arrive (similar to tail -f):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -f<\/code><\/pre>\n\n\n\n<p>To follow a specific service:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service -f<\/code><\/pre>\n\n\n\n<p>This is useful when restarting services or reproducing an issue live.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Filtering logs effectively<\/h2>\n\n\n\n<p>Dumping the entire journal rarely helps during an incident. Filtering is where journalctl becomes powerful.<\/p>\n\n\n\n<p>You can filter by time, unit, boot session, priority, and structured fields.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"701\" height=\"714\" src=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-28.png\" alt=\"log filtering process\" class=\"wp-image-1120\" srcset=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-28.png 701w, https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-28-295x300.png 295w\" sizes=\"auto, (max-width: 701px) 100vw, 701px\" \/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Filter by time<\/h3>\n\n\n\n<p>If you know roughly when something broke, start with time filters.<\/p>\n\n\n\n<p>Use <code>--since<\/code> and <code>--until<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --since \"2026-02-13 10:00\" --until \"2026-02-13 11:00\"<\/code><\/pre>\n\n\n\n<p>You can also use relative time:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --since \"1 hour ago\"\njournalctl --since \"30 minutes ago\"\njournalctl --since today<\/code><\/pre>\n\n\n\n<p>Relative time is especially useful during live incident response.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Filter by service and unit<\/h3>\n\n\n\n<p>To view logs for a specific systemd unit:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service<\/code><\/pre>\n\n\n\n<p>Combine with time filtering:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service --since \"1 hour ago\"<\/code><\/pre>\n\n\n\n<p>You can filter multiple units in one command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service -u php-fpm.service<\/code><\/pre>\n\n\n\n<p>This helps when debugging interactions between services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Filter by boot session<\/h3>\n\n\n\n<p>Every boot has a unique ID.<\/p>\n\n\n\n<p>To show logs from the current boot:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -b<\/code><\/pre>\n\n\n\n<p>To view logs from the previous boot:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -b -1<\/code><\/pre>\n\n\n\n<p>To list all boot sessions:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --list-boots<\/code><\/pre>\n\n\n\n<p>This is essential when diagnosing reboot-related issues or crashes that happened before the system came back up.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Filter by priority and severity<\/h3>\n\n\n\n<p>Journald uses standard syslog priority\/<a href=\"https:\/\/uptimerobot.com\/knowledge-hub\/monitoring\/severity-levels-explained\/?utm_source=uptimerobot.com&amp;utm_medium=knowledge-hub&amp;utm_campaign=journalctl-explained&amp;utm_content=filter-severity\" target=\"_blank\" rel=\"noreferrer noopener\">severity levels<\/a>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>0: emerg<\/li>\n\n\n\n<li>1: alert<\/li>\n\n\n\n<li>2: crit<\/li>\n\n\n\n<li>3: err<\/li>\n\n\n\n<li>4: warning<\/li>\n\n\n\n<li>5: notice<\/li>\n\n\n\n<li>6: info<\/li>\n\n\n\n<li>7: debug<\/li>\n<\/ul>\n\n\n\n<p>To show only errors and higher:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -p err<\/code><\/pre>\n\n\n\n<p>To show a range (for example, warnings through emergencies):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -p warning..emerg<\/code><\/pre>\n\n\n\n<p>To filter a specific service by priority:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service -p err --since \"1 hour ago\"<\/code><\/pre>\n\n\n\n<p>This is often the fastest way to isolate meaningful failures.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Advanced filtering using journal fields<\/h2>\n\n\n\n<p>Time and unit filtering are powerful. But when you\u2019re dealing with high-volume systems, you often need more precision.<\/p>\n\n\n\n<p>That\u2019s where journal fields come in.<\/p>\n\n\n\n<p>Each journal entry contains structured metadata. You can match directly against those fields instead of scanning message text.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Matching structured fields directly<\/h3>\n\n\n\n<p>You\u2019ve already seen -u for units. Under the hood, that\u2019s filtering on the _SYSTEMD_UNIT field.<\/p>\n\n\n\n<p>You can filter fields explicitly:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _SYSTEMD_UNIT=nginx.service<\/code><\/pre>\n\n\n\n<p>Other useful fields include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>_PID &#8211; process ID<\/li>\n\n\n\n<li>_COMM &#8211; command name<\/li>\n\n\n\n<li>_EXE &#8211; full executable path<\/li>\n\n\n\n<li>_UID &#8211; user ID<\/li>\n\n\n\n<li>_BOOT_ID &#8211; specific boot session<\/li>\n\n\n\n<li>PRIORITY &#8211; log severity<\/li>\n<\/ul>\n\n\n\n<p>For example, to filter by PID:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _PID=1234<\/code><\/pre>\n\n\n\n<p>To filter by command name:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _COMM=nginx<\/code><\/pre>\n\n\n\n<p>This is especially useful for short-lived processes that may restart frequently.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Combining filters<\/h3>\n\n\n\n<p>You can combine multiple field matches in a single command. They act as logical AND conditions.<\/p>\n\n\n\n<p>Example: errors from nginx in the last hour:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _SYSTEMD_UNIT=nginx.service -p err --since \"1 hour ago\"<\/code><\/pre>\n\n\n\n<p>Example: logs from a specific PID during the current boot:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _PID=1234 -b<\/code><\/pre>\n\n\n\n<p>You can combine unit, priority, and time:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _SYSTEMD_UNIT=sshd.service PRIORITY=3 --since \"30 minutes ago\"<\/code><\/pre>\n\n\n\n<p>The more precise the filter, the less noise you need to sift through.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Why this matters for troubleshooting speed<\/h3>\n\n\n\n<p>On a busy production system, grepping through large log files can take time and return too much irrelevant output.<\/p>\n\n\n\n<p>Field-based filtering gives you:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Faster root cause analysis<\/li>\n\n\n\n<li>Less manual parsing<\/li>\n\n\n\n<li>Cleaner automation pipelines<\/li>\n\n\n\n<li>More confidence that you\u2019re looking at the right events<\/li>\n<\/ul>\n\n\n\n<p>For example, instead of:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl | grep \"connection refused\"<\/code><\/pre>\n\n\n\n<p>You can narrow it first:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _SYSTEMD_UNIT=nginx.service -p err --since \"10 minutes ago\"<\/code><\/pre>\n\n\n\n<p>Then inspect the results. That difference becomes important during an outage, when every minute counts.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Output formats and exporting logs<\/h2>\n\n\n\n<p>journalctl isn\u2019t just for reading logs in a terminal. You can change output formats, export logs to files, and pipe them into other tools.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Short, verbose, and JSON output<\/h3>\n\n\n\n<p>By default, journalctl uses a short, readable format.<\/p>\n\n\n\n<p>For more detail per entry:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -o verbose<\/code><\/pre>\n\n\n\n<p>This shows all available fields, including internal metadata like <code>_SYSTEMD_UNIT<\/code>, <code>_PID, _BOOT_ID<\/code>, and more. It\u2019s useful when you\u2019re trying to understand exactly how an entry is structured.<\/p>\n\n\n\n<p>For machine-readable output:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -o json<\/code><\/pre>\n\n\n\n<p>Each log entry is printed as a JSON object on a single line.<\/p>\n\n\n\n<p>For easier human inspection:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -o json-pretty<\/code><\/pre>\n\n\n\n<p>JSON output is ideal for scripts, automation, and log processing pipelines.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When to use JSON<\/h3>\n\n\n\n<p>Use JSON when you need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Structured parsing<\/li>\n\n\n\n<li>Field extraction<\/li>\n\n\n\n<li>Integration with tools like jq<\/li>\n\n\n\n<li>Automated log checks<\/li>\n<\/ul>\n\n\n\n<p>Example: extract only the message field:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service -o json --no-pager | jq -r '.MESSAGE'<\/code><\/pre>\n\n\n\n<p>Example: count errors from the last hour:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -p err --since \"1 hour ago\" -o json --no-pager | jq -r '.MESSAGE' | wc -l<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Exporting logs to a file<\/h3>\n\n\n\n<p>You can redirect output to a file for sharing or incident documentation:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service --since \"1 hour ago\" --no-pager &gt; nginx.log<\/code><\/pre>\n\n\n\n<p>For structured export:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --since \"today\" -o json --no-pager &gt; logs.json<\/code><\/pre>\n\n\n\n<p>This is useful for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Attaching logs to support tickets<\/li>\n\n\n\n<li>Feeding logs into analysis tools<\/li>\n\n\n\n<li>Creating post-incident artifacts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Piping into other tools<\/h3>\n\n\n\n<p>Because journalctl works well in pipelines, you can combine it with other CLI tools:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u sshd.service --since \"1 day ago\" --no-pager | grep \"Failed password\"<\/code><\/pre>\n\n\n\n<p>Or with structured filtering:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -p warning --since \"2 hours ago\" -o json --no-pager | jq '._SYSTEMD_UNIT'<\/code><\/pre>\n\n\n\n<p>This makes journalctl suitable not just for manual troubleshooting, but for automation and reporting.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Real world troubleshooting scenarios<\/h2>\n\n\n\n<p>journalctl becomes powerful when you use it with intent. Below are common incident scenarios and the exact patterns that help you move quickly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Diagnosing a failed service after reboot<\/h3>\n\n\n\n<p>Symptom: a service is down after a reboot.<\/p>\n\n\n\n<p><strong>Step 1:<\/strong> confirm the failure.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl --failed<\/code><\/pre>\n\n\n\n<p><strong>Step 2:<\/strong> inspect logs from the current boot for that unit.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u my-app.service -b<\/code><\/pre>\n\n\n\n<p><strong>Step 3:<\/strong> narrow to errors only.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u my-app.service -b -p err<\/code><\/pre>\n\n\n\n<p>If the issue started during the previous boot:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -b -1\njournalctl -u my-app.service -b -1<\/code><\/pre>\n\n\n\n<p>This quickly tells you whether the failure is tied to boot-time dependencies, missing environment variables, or permission errors.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Finding kernel or hardware errors<\/h3>\n\n\n\n<p>Symptom: random crashes, network drops, or system instability.<\/p>\n\n\n\n<p>Start with kernel logs:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -k<\/code><\/pre>\n\n\n\n<p>Limit to the current boot:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -k -b<\/code><\/pre>\n\n\n\n<p>Focus on high-severity entries:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -k -p warning..emerg<\/code><\/pre>\n\n\n\n<p>Look for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>I\/O errors<\/li>\n\n\n\n<li>Network interface resets<\/li>\n\n\n\n<li>OOM killer messages<\/li>\n\n\n\n<li>Filesystem corruption warnings<\/li>\n<\/ul>\n\n\n\n<p>This isolates hardware and kernel-level issues without scanning application logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tracking intermittent service crashes<\/h3>\n\n\n\n<p>Symptom: a service restarts sporadically.<\/p>\n\n\n\n<p><strong>Step 1:<\/strong> check restart events.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service<\/code><\/pre>\n\n\n\n<p><strong>Step 2: <\/strong>filter for the last few hours.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service --since \"3 hours ago\"<\/code><\/pre>\n\n\n\n<p><strong>Step 3:<\/strong> narrow to errors and critical events.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service -p err --since \"3 hours ago\"<\/code><\/pre>\n\n\n\n<p>If the service restarts rapidly, filtering by boot or PID helps:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl _SYSTEMD_UNIT=nginx.service\njournalctl _PID=1234<\/code><\/pre>\n\n\n\n<p>This helps distinguish configuration issues from runtime crashes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Debugging slow boot times<\/h3>\n\n\n\n<p>Symptom: system boots slowly after updates.<\/p>\n\n\n\n<p>Start with boot logs:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -b<\/code><\/pre>\n\n\n\n<p>Then check systemd timing:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemd-analyze blame<\/code><\/pre>\n\n\n\n<p>Use journalctl to inspect slow units:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u network.service -b\njournalctl -u docker.service -b<\/code><\/pre>\n\n\n\n<p>Focus on units that:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Wait on dependencies<\/li>\n\n\n\n<li>Timeout during startup<\/li>\n\n\n\n<li>Retry connections repeatedly<\/li>\n<\/ul>\n\n\n\n<p>Filtering by time can also help if you know when the delay occurs:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -b --since \"10 minutes ago\"<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Investigating unexpected reboots<\/h3>\n\n\n\n<p>Symptom: the server rebooted without warning.<\/p>\n\n\n\n<p>Check the previous boot:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -b -1<\/code><\/pre>\n\n\n\n<p>Look at the last entries before shutdown:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -b -1 -n 100<\/code><\/pre>\n\n\n\n<p>Search for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Out of memory<\/li>\n\n\n\n<li>Kernel panic<\/li>\n\n\n\n<li>Power or ACPI errors<\/li>\n\n\n\n<li>Watchdog triggers<\/li>\n<\/ul>\n\n\n\n<p>This often reveals whether the reboot was triggered by the kernel, hardware, or a controlled restart.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Using journalctl in scripts and automation<\/h2>\n\n\n\n<p>journalctl isn\u2019t just for manual debugging. It works well in scripts, <a href=\"https:\/\/uptimerobot.com\/cron-job-monitoring\/?utm_source=uptimerobot.com&amp;utm_medium=knowledge-hub&amp;utm_campaign=journalctl-explained&amp;utm_content=using-journalctl\" target=\"_blank\" rel=\"noreferrer noopener\">cron jobs<\/a>, and <a href=\"https:\/\/uptimerobot.com\/website-monitoring\/?utm_source=uptimerobot.com&amp;utm_medium=knowledge-hub&amp;utm_campaign=journalctl-explained&amp;utm_content=using-journalctl\" target=\"_blank\" rel=\"noreferrer noopener\">monitoring<\/a> checks, especially when you control the output format.<\/p>\n\n\n\n    <div class=\"wp-block-knowledge-hub-theme-intext-sidebar ur-intext-sidebar\">\n        <div class=\"widget-img\">\n            <img decoding=\"async\" src=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/themes\/generatepress-child\/assets\/images\/img-intext-sidebar.png\" alt=\"UptimeRobot\">\n        <\/div>\n        <div class=\"widget-left\">\n            <div class=\"widget-title\">\n                <span>Downtime happens.<\/span>\n                <span class=\"text-primary\">Get notified!<\/span>\n            <\/div>\n            <div class=\"widget-text\">Join the world&#039;s leading uptime monitoring service with 3.2M+ happy users.<\/div>\n        <\/div>\n        <div class=\"widget-button\">\n            <a href=\"https:\/\/dashboard.uptimerobot.com\/sign-up?utm_source=uptimerobot&#038;utm_medium=kh&#038;utm_campaign=intext-sidebar\" class=\"button\">\n                <span>Register for FREE<\/span>\n            <\/a>\n        <\/div>\n    <\/div>\n    \n\n\n\n<p>The key is to keep output predictable and scoped.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Non-interactive usage<\/h3>\n\n\n\n<p>When using journalctl in scripts, always disable paging:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --no-pager<\/code><\/pre>\n\n\n\n<p>You\u2019ll usually also want to narrow the time window:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --since \"5 minutes ago\" --no-pager<\/code><\/pre>\n\n\n\n<p>This prevents scanning the entire journal and keeps execution fast.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Exit codes and predictable output<\/h3>\n\n\n\n<p>journalctl exits with status 0 even if no logs match.<\/p>\n\n\n\n<p>So instead of checking exit codes, check whether output is empty.<\/p>\n\n\n\n<p>Example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>if ! journalctl -u nginx.service --since \"5 minutes ago\" --no-pager | grep -q .; then\n  echo \"No recent logs for nginx\"\nfi<\/code><\/pre>\n\n\n\n<p>If you\u2019re alerting on errors:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>if journalctl -u nginx.service -p err --since \"5 minutes ago\" --no-pager | grep -q .; then\n  echo \"Errors detected\"\nfi<\/code><\/pre>\n\n\n\n<p>This pattern works well in health checks.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Using journalctl in cron jobs<\/h3>\n\n\n\n<p>Example: email errors every 10 minutes.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>*\/10 * * * * journalctl -p err --since \"10 minutes ago\" --no-pager | mail -s \"System Errors\" ops@example.com<\/code><\/pre>\n\n\n\n<p>Always use relative time filters in scheduled jobs to avoid overlapping windows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Structured output for automation<\/h3>\n\n\n\n<p>For machine parsing, use JSON:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u myapp.service --since \"15 minutes ago\" -o json --no-pager<\/code><\/pre>\n\n\n\n<p>Then extract fields with jq:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u myapp.service --since \"15 minutes ago\" -o json --no-pager \\\n&nbsp;&nbsp;| jq -r '.MESSAGE'<\/code><\/pre>\n\n\n\n<p>This makes it possible to:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Count error types<\/li>\n\n\n\n<li>Detect specific failure patterns<\/li>\n\n\n\n<li>Trigger webhooks or alerts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Log-based health checks<\/h3>\n\n\n\n<p>You can build simple health checks based on recent log activity.<\/p>\n\n\n\n<p>Example: alert if no successful start message appears:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>if ! journalctl -u myapp.service --since \"5 minutes ago\" --no-pager | grep -q \"Started successfully\"; then\n  echo \"Service may not be healthy\"\nfi<\/code><\/pre>\n\n\n\n<p>This is basic, but effective for lightweight monitoring setups.<\/p>\n\n\n\n<p>journalctl works well locally. But once you need correlation across multiple systems, you\u2019ll usually forward logs into a centralized stack.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Integrating journalctl with monitoring and observability tools<\/h2>\n\n\n\n<p>journalctl is great for local debugging, but it\u2019s not a long-term log platform. For production systems, you\u2019ll usually forward journald logs into a centralized pipeline so you can search across hosts, retain logs longer, and alert on patterns.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"949\" height=\"737\" src=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-29.png\" alt=\"log pipeline cycle\" class=\"wp-image-1121\" srcset=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-29.png 949w, https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-29-300x233.png 300w, https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-29-768x596.png 768w\" sizes=\"auto, (max-width: 949px) 100vw, 949px\" \/><\/figure>\n<\/div>\n\n\n<h3 class=\"wp-block-heading\">Forwarding logs to external systems<\/h3>\n\n\n\n<p>Most stacks use one of these patterns:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>journald \u2192 syslog daemon (rsyslog\/syslog-ng) \u2192 log shipper \u2192 log backend<br><\/li>\n\n\n\n<li>journald \u2192 log shipper that reads the journal directly \u2192 log backend<\/li>\n<\/ul>\n\n\n\n<p>If you\u2019re using a syslog daemon, journald can forward into it.&nbsp;<\/p>\n\n\n\n<p>In journald.conf:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ForwardToSyslog=yes<\/code><\/pre>\n\n\n\n<p>From there, your syslog daemon can write to files or forward to a remote destination.<\/p>\n\n\n\n<p>If you\u2019re using a log shipper that reads journald directly, you typically filter on fields like <code>_SYSTEMD_UNIT<\/code> and follow from the tail so you only ingest new entries.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Using journald as a source of truth<\/h3>\n\n\n\n<p>Even if you forward logs elsewhere, journald is often your fastest \u201csource of truth\u201d during an incident because:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>It\u2019s local to the host.<\/li>\n\n\n\n<li>It includes unit and boot context.<\/li>\n\n\n\n<li>It supports high-precision filtering without extra parsing.<\/li>\n<\/ul>\n\n\n\n<p>A common workflow looks like:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use dashboards to spot the time window and affected hosts.<\/li>\n\n\n\n<li>Use journalctl on the host to confirm what actually happened.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common integration patterns (conceptual)<\/h3>\n\n\n\n<p>Teams usually ship logs into systems like:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>ELK-style pipelines (Elasticsearch + Logstash\/Beats + Kibana)<\/li>\n\n\n\n<li>Loki-style pipelines (Promtail\/agent + Loki + Grafana)<\/li>\n\n\n\n<li>Graylog-style pipelines (inputs + processing + search)<\/li>\n\n\n\n<li>Splunk-style pipelines (forwarders + indexing + search)<\/li>\n<\/ul>\n\n\n\n<p>The exact tooling varies, but the idea is consistent:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Read from journald<\/li>\n\n\n\n<li>Preserve structured fields where possible<\/li>\n\n\n\n<li>Add host and environment tags<\/li>\n\n\n\n<li>Route logs to a central backend for search and alerts<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Managing disk usage and performance<\/h2>\n\n\n\n<p>Journald is easy to ignore until it eats disk space or you lose logs you needed after a reboot. A few checks and settings keep it predictable on production systems.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Check journal size<\/h3>\n\n\n\n<p>Start with a quick disk usage check:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --disk-usage<\/code><\/pre>\n\n\n\n<p>If it\u2019s larger than you expect, you can also check where logs are stored:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>\/run\/log\/journal\/<\/code>: volatile (cleared on reboot)<\/li>\n\n\n\n<li><code>\/var\/log\/journal\/<\/code>: persistent (survives reboot)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Limit disk usage and retention<\/h3>\n\n\n\n<p>Journald retention is controlled in:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/systemd\/journald.conf<\/code><\/pre>\n\n\n\n<p>Common settings include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>SystemMaxUse<\/code>: cap total disk usage for persistent logs<\/li>\n\n\n\n<li><code>SystemKeepFree<\/code>: keep a minimum amount of free disk space<\/li>\n\n\n\n<li><code>SystemMaxFileSize<\/code>: cap individual journal file sizes<\/li>\n\n\n\n<li><code>SystemMaxFiles<\/code>: cap number of archived journal files<\/li>\n<\/ul>\n\n\n\n<p>Example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#091;Journal]\nSystemMaxUse=500M\nSystemKeepFree=1G\nSystemMaxFileSize=50M\nSystemMaxFiles=10<\/code><\/pre>\n\n\n\n<p>After changes:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo systemctl restart systemd-journald<\/code><\/pre>\n\n\n\n<p>On busy hosts, caps like these prevent journald from quietly filling a filesystem.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Vacuum old logs<\/h3>\n\n\n\n<p>If you need to reclaim space quickly, journalctl can delete older entries.<\/p>\n\n\n\n<p>Remove entries older than 7 days:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl --vacuum-time=7d<\/code><\/pre>\n\n\n\n<p>Limit total journal size:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl --vacuum-size=200M<\/code><\/pre>\n\n\n\n<p>Limit the number of archived files:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo journalctl --vacuum-files=5<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Performance considerations on busy systems<\/h3>\n\n\n\n<p>A few practical notes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Wide-open queries are slow: always scope by time, unit, boot, or priority on large hosts.<\/li>\n\n\n\n<li>Persistent logging is usually worth it: volatile-only logs disappear on reboot, which is when you often need logs most.<\/li>\n\n\n\n<li>Disk pressure matters: if a partition runs low on free space, logging can become a reliability problem, not just a convenience feature.<\/li>\n<\/ul>\n\n\n\n<p>If you treat journald like any other production component (limits, retention, and monitoring), it stays useful instead of becoming a liability.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Security and permissions in journalctl<\/h2>\n\n\n\n<p>System logs often contain sensitive data: authentication attempts, service errors, environment details, even stack traces. Access to the journal should be controlled deliberately.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Why root access is usually required<\/h3>\n\n\n\n<p>By default:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>root<\/code> can read the entire system journal.<\/li>\n\n\n\n<li>Regular users can only read their own user session logs.<\/li>\n<\/ul>\n\n\n\n<p>If a non-privileged user runs:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl<\/code><\/pre>\n\n\n\n<p>They\u2019ll typically see limited output unless permissions have been adjusted.<\/p>\n\n\n\n<p>This default protects:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Authentication logs<\/li>\n\n\n\n<li>System service errors<\/li>\n\n\n\n<li>Kernel messages<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Granting read-only access safely<\/h3>\n\n\n\n<p>Instead of giving someone full root access, add them to the <code>systemd-journal<\/code> group:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo usermod -aG systemd-journal username<\/code><\/pre>\n\n\n\n<p>After logging out and back in, that user can read the full journal without needing sudo.<\/p>\n\n\n\n<p>This is common for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SREs<\/li>\n\n\n\n<li>Platform engineers<\/li>\n\n\n\n<li>Incident responders<\/li>\n<\/ul>\n\n\n\n<p>It provides visibility without shell-level root access.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Group-based permissions and journal files<\/h3>\n\n\n\n<p>Persistent journals live under:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/var\/log\/journal\/<\/code><\/pre>\n\n\n\n<p>Files are owned by:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>root<\/li>\n\n\n\n<li>group: systemd-journal<\/li>\n<\/ul>\n\n\n\n<p>Permissions typically look like:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>-rw-r-----&nbsp; root systemd-journal<\/code><\/pre>\n\n\n\n<p>This ensures:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Only root and the journal group can read entries.<\/li>\n\n\n\n<li>Unauthorized users can\u2019t inspect or tamper with logs.<br><\/li>\n<\/ul>\n\n\n\n<p>If you enable persistent storage manually, make sure ownership and permissions are correct:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo mkdir -p \/var\/log\/journal\nsudo chown root:systemd-journal \/var\/log\/journal\nsudo chmod 2755 \/var\/log\/journal<\/code><\/pre>\n\n\n\n<p>The setgid bit (2) keeps group ownership consistent for new files.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Auditing considerations<\/h3>\n\n\n\n<p>Because journald stores authentication and system-level events, it often plays a role in audit and compliance workflows.<\/p>\n\n\n\n<p>Common practices include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Forwarding logs to a centralized logging system.<\/li>\n\n\n\n<li>Restricting journal access to specific roles.<\/li>\n\n\n\n<li>Retaining logs according to policy (for example, 30\u201390 days).<\/li>\n<\/ul>\n\n\n\n<p>If logs are part of an audit trail, volatile-only storage (<code>\/run\/log\/journal<\/code>) is usually insufficient.<\/p>\n\n\n\n<p>Persistent storage plus centralized export is the safer default for production.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">journalctl best practices for production systems<\/h2>\n\n\n\n<p>In production, logs aren\u2019t just for debugging. They\u2019re part of your reliability and <a href=\"https:\/\/uptimerobot.com\/knowledge-hub\/devops\/incident-response-plan\/?utm_source=uptimerobot.com&amp;utm_medium=knowledge-hub&amp;utm_campaign=journalctl-explained&amp;utm_content=best-practices\" target=\"_blank\" rel=\"noreferrer noopener\">incident response workflow<\/a>. A few habits make journalctl far more effective under pressure.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Define a retention strategy<\/h3>\n\n\n\n<p>Unbounded logs are a liability.<\/p>\n\n\n\n<p>Set size or time limits in <code>journald.conf<\/code>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SystemMaxUse<\/li>\n\n\n\n<li>SystemKeepFree<\/li>\n\n\n\n<li>MaxRetentionSec<\/li>\n<\/ul>\n\n\n\n<p>Pick values that match your environment:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Small VM: tighter caps.<\/li>\n\n\n\n<li>Critical host: larger retention plus central forwarding.<\/li>\n<\/ul>\n\n\n\n<p>Don\u2019t rely on defaults. Make retention explicit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Enable persistent logging<\/h3>\n\n\n\n<p>If \/var\/log\/journal doesn\u2019t exist, logs may disappear after reboot.<\/p>\n\n\n\n<p>On production systems, persistent logs are usually expected.<\/p>\n\n\n\n<p>Enable them:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo mkdir -p \/var\/log\/journal\nsudo systemctl restart systemd-journald<\/code><\/pre>\n\n\n\n<p>Reboot-related incidents are hard enough without losing the evidence.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Always scope your queries<\/h3>\n\n\n\n<p>Avoid running:<\/p>\n\n\n\n<p>journalctl<\/p>\n\n\n\n<p>On large systems, that\u2019s slow and noisy.<\/p>\n\n\n\n<p>Instead, scope by:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Unit (-u)<\/li>\n\n\n\n<li>Boot (-b)<\/li>\n\n\n\n<li>Time (&#8211;since)<\/li>\n\n\n\n<li>Priority (-p)<\/li>\n<\/ul>\n\n\n\n<p>Example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u api.service -b -p err --since \"30 minutes ago\"<\/code><\/pre>\n\n\n\n<p>Scoped queries are faster and easier to reason about during incidents.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitor journal health<\/h3>\n\n\n\n<p>Check disk usage periodically:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --disk-usage<\/code><\/pre>\n\n\n\n<p>Watch for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Rapid growth<\/li>\n\n\n\n<li>Logs filling a shared partition<\/li>\n\n\n\n<li>Services spamming debug-level output<\/li>\n<\/ul>\n\n\n\n<p>Excessive logging can turn into a performance problem.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Archive or export when necessary<\/h3>\n\n\n\n<p>Journald works well locally, but it isn\u2019t a long-term analytics platform.<\/p>\n\n\n\n<p>In production:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Forward logs to a centralized system.<\/li>\n\n\n\n<li>Keep local retention reasonable.<\/li>\n\n\n\n<li>Avoid treating journald as permanent storage.<\/li>\n<\/ul>\n\n\n\n<p>This keeps hosts lightweight while maintaining audit visibility elsewhere.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">SRE-oriented checklist<\/h3>\n\n\n\n<p>Use this as a quick sanity check:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Persistent logging enabled<\/li>\n\n\n\n<li>Retention limits configured<\/li>\n\n\n\n<li>Logs forwarded to central stack<\/li>\n\n\n\n<li>Query patterns standardized for incidents<\/li>\n\n\n\n<li>Journal disk usage monitored<\/li>\n<\/ul>\n\n\n\n<p>If those are in place, journalctl becomes a fast, reliable diagnostic tool instead of a reactive scramble.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Common journalctl mistakes to avoid<\/h2>\n\n\n\n<p>Even experienced engineers misuse journalctl under pressure. Most issues come down to filtering too loosely or assuming defaults behave a certain way.<\/p>\n\n\n\n<p>Here are the mistakes that waste the most time.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Relying only on grep<\/h3>\n\n\n\n<p>It\u2019s tempting to run:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl | grep \"error\"<\/code><\/pre>\n\n\n\n<p>That works, but it ignores structured fields and can miss context.<\/p>\n\n\n\n<p>Better:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -p err\njournalctl -u nginx.service -p err<\/code><\/pre>\n\n\n\n<p>Use built-in filters first. Use grep only when you need message-level pattern matching.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Ignoring boot filtering<\/h3>\n\n\n\n<p>Logs span multiple boots. If you forget -b, you may mix events from different sessions.<\/p>\n\n\n\n<p>Instead of:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u my-app.service<\/code><\/pre>\n\n\n\n<p>Try:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -u my-app.service -b<\/code><\/pre>\n\n\n\n<p>Or check the previous boot explicitly:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl -b -1<\/code><\/pre>\n\n\n\n<p>Boot filtering is one of the fastest ways to isolate restart-related issues.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Running unscoped queries on large systems<\/h3>\n\n\n\n<p>Running\u2026<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl<\/code><\/pre>\n\n\n\n<p>\u2026on a busy host can dump massive output and slow you down.<\/p>\n\n\n\n<p>Always scope by:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Time (&#8211;since)<\/li>\n\n\n\n<li>Unit (-u)<\/li>\n\n\n\n<li>Priority (-p)<\/li>\n\n\n\n<li>Boot (-b)<\/li>\n<\/ul>\n\n\n\n<p>Small filters make big systems manageable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Letting disk usage grow unchecked<\/h3>\n\n\n\n<p>If retention isn\u2019t configured, journals can grow until the disk fills.<\/p>\n\n\n\n<p>Check usage:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>journalctl --disk-usage<\/code><\/pre>\n\n\n\n<p>Set limits in <code>journald.conf<\/code> and monitor them like any other system component.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">No log export strategy<\/h3>\n\n\n\n<p>Journald is excellent locally, but it isn\u2019t a <a href=\"https:\/\/uptimerobot.com\/blog\/observability-tools\/?utm_source=uptimerobot.com&amp;utm_medium=knowledge-hub&amp;utm_campaign=journalctl-explained&amp;utm_content=mistakes\" target=\"_blank\" rel=\"noreferrer noopener\">full observability stack<\/a>.<\/p>\n\n\n\n<p>If logs only live on the host:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You lose cross-host visibility.<\/li>\n\n\n\n<li>You risk losing logs if a disk fails.<\/li>\n\n\n\n<li>Incident analysis becomes harder.<\/li>\n<\/ul>\n\n\n\n<p>Forward logs to a centralized system and keep journald focused on fast local diagnostics.<\/p>\n\n\n\n<p>Avoid these pitfalls and journalctl becomes predictable instead of frustrating.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">journalctl command cheatsheet<\/h2>\n\n\n\n<p>Use this as a quick reference during troubleshooting.<\/p>\n\n\n\n<figure class=\"wp-block-table aligncenter\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Goal<\/strong><\/td><td><strong>Command<\/strong><\/td><\/tr><tr><td>View all logs<\/td><td>journalctl<\/td><\/tr><tr><td>Newest first<\/td><td>journalctl -r<\/td><\/tr><tr><td>Last 100 lines<\/td><td>journalctl -n 100<\/td><\/tr><tr><td>Follow logs in real time<\/td><td>journalctl -f<\/td><\/tr><tr><td>Logs for a service<\/td><td>journalctl -u nginx.service<\/td><\/tr><tr><td>Service logs (current boot)<\/td><td>journalctl -u nginx.service -b<\/td><\/tr><tr><td>Current boot only<\/td><td>journalctl -b<\/td><\/tr><tr><td>Previous boot<\/td><td>journalctl -b -1<\/td><\/tr><tr><td>List all boots<\/td><td>journalctl &#8211;list-boots<\/td><\/tr><tr><td>Since specific time<\/td><td>journalctl &#8211;since &#8220;2026-02-13 10:00&#8221;<\/td><\/tr><tr><td>Relative time filter<\/td><td>journalctl &#8211;since &#8220;1 hour ago&#8221;<\/td><\/tr><tr><td>Filter by priority<\/td><td>journalctl -p err<\/td><\/tr><tr><td>Priority range<\/td><td>journalctl -p warning..emerg<\/td><\/tr><tr><td>Kernel logs only<\/td><td>journalctl -k<\/td><\/tr><tr><td>Filter by PID<\/td><td>journalctl _PID=1234<\/td><\/tr><tr><td>JSON output<\/td><td>journalctl -o json<\/td><\/tr><tr><td>Pretty JSON<\/td><td>journalctl -o json-pretty<\/td><\/tr><tr><td>Disable pager (scripts)<\/td><td>journalctl &#8211;no-pager<\/td><\/tr><tr><td>Check disk usage<\/td><td>journalctl &#8211;disk-usage<\/td><\/tr><tr><td>Vacuum logs by time<\/td><td>sudo journalctl &#8211;vacuum-time=7d<\/td><\/tr><tr><td>Vacuum logs by size<\/td><td>sudo journalctl &#8211;vacuum-size=200M<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>If you remember nothing else:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Scope by service: <code>-u<\/code><\/li>\n\n\n\n<li>Scope by boot: <code>-b<\/code><\/li>\n\n\n\n<li>Scope by time: <code>--since<\/code><\/li>\n\n\n\n<li>Scope by severity: <code>-p<\/code><\/li>\n<\/ul>\n\n\n\n<p>Those four filters solve most incidents quickly.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion: when journalctl becomes a superpower<\/h2>\n\n\n\n<p>At first glance, journalctl looks like just another way to read logs. In practice, it\u2019s much more than that.<\/p>\n\n\n\n<p>Once you start combining filters like unit, boot, time, priority, and structured fields, it becomes a fast query engine for system events. Instead of grepping through multiple files, you\u2019re narrowing down indexed data in seconds.<\/p>\n\n\n\n<p>That shift matters during real incidents.<\/p>\n\n\n\n<p>When you:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Filter by boot to isolate restart-related failures<\/li>\n\n\n\n<li>Narrow by unit to focus on one service<\/li>\n\n\n\n<li>Use priority levels to cut through noise<\/li>\n\n\n\n<li>Query structured fields like <code>_SYSTEMD_UNIT<\/code>, <code>_PID<\/code>, and <code>_BOOT_ID<\/code><\/li>\n<\/ul>\n\n\n\n<p>You move from reactive searching to targeted debugging.<\/p>\n\n\n\n<p>In modern Linux environments built on systemd, journalctl is often the quickest path to answers. Paired with sensible retention settings and centralized log forwarding, it fits cleanly into a production-ready logging strategy.<\/p>\n\n\n\n<p>Master the filters, keep your queries scoped, and treat logs as structured data. That\u2019s when journalctl stops feeling like a command and starts feeling like leverage.<\/p>\n\n\n\n    <div class=\"wp-block-knowledge-hub-theme-intext-sidebar ur-intext-sidebar\">\n        <div class=\"widget-img\">\n            <img decoding=\"async\" src=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/themes\/generatepress-child\/assets\/images\/img-intext-sidebar.png\" alt=\"UptimeRobot\">\n        <\/div>\n        <div class=\"widget-left\">\n            <div class=\"widget-title\">\n                <span>Downtime happens.<\/span>\n                <span class=\"text-primary\">Get notified!<\/span>\n            <\/div>\n            <div class=\"widget-text\">Join the world&#039;s leading uptime monitoring service with 3.2M+ happy users.<\/div>\n        <\/div>\n        <div class=\"widget-button\">\n            <a href=\"https:\/\/dashboard.uptimerobot.com\/sign-up?utm_source=uptimerobot&#038;utm_medium=kh&#038;utm_campaign=intext-sidebar\" class=\"button\">\n                <span>Register for FREE<\/span>\n            <\/a>\n        <\/div>\n    <\/div>\n    \n\n\n\n<div id=\"faq\" class=\"faq-block py-8 \">\n            <h2 id=\"faqs\" class=\"faq-block__title\">\n            FAQ&#039;s        <\/h2>\n    \n    <ul class=\"faq-accordion\" data-faq-accordion>\n                    <li class=\"faq-accordion__item\">\n                <button \n                    class=\"faq-accordion__title\"\n                    type=\"button\"\n                    aria-expanded=\"false\"\n                    data-faq-trigger>\n                    <h3 id=\"what-is-journalctl-in-linux\" class=\"faq-accordion__question\">\n                        What is journalctl in Linux?                    <\/h3>\n                    <span class=\"faq-accordion__icon\" aria-hidden=\"true\">+<\/span>\n                <\/button>\n                <div class=\"faq-accordion__content-wrapper\">\n                    <div class=\"faq-accordion__content\">\n                        <div class=\"faq-accordion__content-inner\">\n                            <!-- wp:paragraph -->\n<p><code>journalctl<\/code> is a command-line tool used to view and query logs collected by systemd-journald on Linux systems. It provides access to system, kernel, and service logs in one place and allows filtering by time, boot session, service, process ID, or severity level for faster troubleshooting.<\/p>\n<!-- \/wp:paragraph -->                        <\/div>\n                    <\/div>\n                <\/div>\n            <\/li>\n                    <li class=\"faq-accordion__item\">\n                <button \n                    class=\"faq-accordion__title\"\n                    type=\"button\"\n                    aria-expanded=\"false\"\n                    data-faq-trigger>\n                    <h3 id=\"what-is-the-difference-between-journalctl-and-syslog\" class=\"faq-accordion__question\">\n                        What is the difference between journalctl and syslog?                    <\/h3>\n                    <span class=\"faq-accordion__icon\" aria-hidden=\"true\">+<\/span>\n                <\/button>\n                <div class=\"faq-accordion__content-wrapper\">\n                    <div class=\"faq-accordion__content\">\n                        <div class=\"faq-accordion__content-inner\">\n                            <!-- wp:paragraph -->\n<p><code>journalctl<\/code> reads structured logs stored by systemd in a binary journal, while syslog systems store logs as plain text files under <code>\/var\/log<\/code>. Journald provides indexed fields, faster queries, and unified logs across services and kernel events, while syslog offers simpler text-based storage and broader compatibility.<\/p>\n<!-- \/wp:paragraph -->                        <\/div>\n                    <\/div>\n                <\/div>\n            <\/li>\n                    <li class=\"faq-accordion__item\">\n                <button \n                    class=\"faq-accordion__title\"\n                    type=\"button\"\n                    aria-expanded=\"false\"\n                    data-faq-trigger>\n                    <h3 id=\"where-are-journalctl-logs-stored\" class=\"faq-accordion__question\">\n                        Where are journalctl logs stored?                    <\/h3>\n                    <span class=\"faq-accordion__icon\" aria-hidden=\"true\">+<\/span>\n                <\/button>\n                <div class=\"faq-accordion__content-wrapper\">\n                    <div class=\"faq-accordion__content\">\n                        <div class=\"faq-accordion__content-inner\">\n                            <!-- wp:paragraph -->\n<p>ournal logs are stored in:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:list -->\n<ul class=\"wp-block-list\"><!-- wp:list-item -->\n<li><code>\/run\/log\/journal\/<\/code> \u2192 temporary logs cleared after reboot<\/li>\n<!-- \/wp:list-item -->\n\n<!-- wp:list-item -->\n<li><code>\/var\/log\/journal\/<\/code> \u2192 persistent logs that survive reboots<\/li>\n<!-- \/wp:list-item --><\/ul>\n<!-- \/wp:list -->\n\n<!-- wp:paragraph -->\n<p>If persistent storage is not enabled, logs may disappear after a system restart.<\/p>\n<!-- \/wp:paragraph -->                        <\/div>\n                    <\/div>\n                <\/div>\n            <\/li>\n                    <li class=\"faq-accordion__item\">\n                <button \n                    class=\"faq-accordion__title\"\n                    type=\"button\"\n                    aria-expanded=\"false\"\n                    data-faq-trigger>\n                    <h3 id=\"how-do-i-check-logs-for-a-specific-service-using-journalctl\" class=\"faq-accordion__question\">\n                        How do I check logs for a specific service using journalctl?                    <\/h3>\n                    <span class=\"faq-accordion__icon\" aria-hidden=\"true\">+<\/span>\n                <\/button>\n                <div class=\"faq-accordion__content-wrapper\">\n                    <div class=\"faq-accordion__content\">\n                        <div class=\"faq-accordion__content-inner\">\n                            <!-- wp:paragraph -->\n<p>Use the <code>-u<\/code> option followed by the service name:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>You can combine it with filters like time or severity:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>journalctl -u nginx.service --since \"1 hour ago\" -p err<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>This helps isolate service failures quickly.<\/p>\n<!-- \/wp:paragraph -->                        <\/div>\n                    <\/div>\n                <\/div>\n            <\/li>\n                    <li class=\"faq-accordion__item\">\n                <button \n                    class=\"faq-accordion__title\"\n                    type=\"button\"\n                    aria-expanded=\"false\"\n                    data-faq-trigger>\n                    <h3 id=\"why-does-journalctl-require-root-permissions\" class=\"faq-accordion__question\">\n                        Why does journalctl require root permissions?                    <\/h3>\n                    <span class=\"faq-accordion__icon\" aria-hidden=\"true\">+<\/span>\n                <\/button>\n                <div class=\"faq-accordion__content-wrapper\">\n                    <div class=\"faq-accordion__content\">\n                        <div class=\"faq-accordion__content-inner\">\n                            <!-- wp:paragraph -->\n<p>System logs often contain sensitive information such as authentication attempts, system errors, and kernel messages. By default, only root or users in the <code>systemd-journal<\/code> group can access the full journal to protect system security and audit data.<\/p>\n<!-- \/wp:paragraph -->                        <\/div>\n                    <\/div>\n                <\/div>\n            <\/li>\n            <\/ul>\n<\/div>\n\n<script type=\"application\/ld+json\">\n{\"@context\":\"https:\/\/schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What is journalctl in Linux?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"journalctl is a command-line tool used to view and query logs collected by systemd-journald on Linux systems. It provides access to system, kernel, and service logs in one place and allows filtering by time, boot session, service, process ID, or severity level for faster troubleshooting.\"}},{\"@type\":\"Question\",\"name\":\"What is the difference between journalctl and syslog?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"journalctl reads structured logs stored by systemd in a binary journal, while syslog systems store logs as plain text files under \/var\/log. Journald provides indexed fields, faster queries, and unified logs across services and kernel events, while syslog offers simpler text-based storage and broader compatibility.\"}},{\"@type\":\"Question\",\"name\":\"Where are journalctl logs stored?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"ournal logs are stored in: \/run\/log\/journal\/ \u2192 temporary logs cleared after reboot \/var\/log\/journal\/ \u2192 persistent logs that survive reboots If persistent storage is not enabled, logs may disappear after a system restart.\"}},{\"@type\":\"Question\",\"name\":\"How do I check logs for a specific service using journalctl?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Use the -u option followed by the service name: journalctl -u nginx.service You can combine it with filters like time or severity: journalctl -u nginx.service --since \\\"1 hour ago\\\" -p err This helps isolate service failures quickly.\"}},{\"@type\":\"Question\",\"name\":\"Why does journalctl require root permissions?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"System logs often contain sensitive information such as authentication attempts, system errors, and kernel messages. By default, only root or users in the systemd-journal group can access the full journal to protect system security and audit data.\"}}]}<\/script>\n","protected":false},"excerpt":{"rendered":"<p>When something breaks on a Linux server, logs are the first place you look. On modern systemd-based systems, that means the systemd journal. journalctl is the command-line tool for querying logs collected by systemd-journald. It pulls together messages from services, the kernel, and user processes, then lets you filter them by time, boot session, unit, [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-1118","post","type-post","status-publish","format-standard","hentry","category-logging"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.9 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Journalctl Explained: How To View And Analyze Systemd Logs - UptimeRobot Knowledge Hub<\/title>\n<meta name=\"description\" content=\"Learn how to use journalctl to view, filter, export, and troubleshoot systemd logs. Includes advanced examples, automation tips and best practices.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Journalctl Explained: How To View And Analyze Systemd Logs - UptimeRobot Knowledge Hub\" \/>\n<meta property=\"og:description\" content=\"Learn how to use journalctl to view, filter, export, and troubleshoot systemd logs. Includes advanced examples, automation tips and best practices.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/\" \/>\n<meta property=\"og:site_name\" content=\"UptimeRobot Knowledge Hub\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-16T10:59:01+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-02-16T11:00:58+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-1024x603.png\" \/>\n<meta name=\"author\" content=\"Laura Clayton\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Laura Clayton\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"18 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/\"},\"author\":{\"name\":\"Laura Clayton\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/person\/c05598f15bcbd26ed4d53240dff2ae34\"},\"headline\":\"Journalctl Explained: How To View And Analyze Systemd Logs\",\"datePublished\":\"2026-02-16T10:59:01+00:00\",\"dateModified\":\"2026-02-16T11:00:58+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/\"},\"wordCount\":3826,\"publisher\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#organization\"},\"image\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-1024x603.png\",\"articleSection\":[\"Logging\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/\",\"url\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/\",\"name\":\"Journalctl Explained: How To View And Analyze Systemd Logs - UptimeRobot Knowledge Hub\",\"isPartOf\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-1024x603.png\",\"datePublished\":\"2026-02-16T10:59:01+00:00\",\"dateModified\":\"2026-02-16T11:00:58+00:00\",\"description\":\"Learn how to use journalctl to view, filter, export, and troubleshoot systemd logs. Includes advanced examples, automation tips and best practices.\",\"breadcrumb\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#primaryimage\",\"url\":\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27.png\",\"contentUrl\":\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27.png\",\"width\":1080,\"height\":636},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Knowledge Hub\",\"item\":\"https:\/\/uptimerobot.com\/knowledge-hub\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Logging\",\"item\":\"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Journalctl Explained: How To View And Analyze Systemd Logs\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#website\",\"url\":\"https:\/\/uptimerobot.com\/knowledge-hub\/\",\"name\":\"UptimeRobot Knowledge Hub\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/uptimerobot.com\/knowledge-hub\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#organization\",\"name\":\"UptimeRobot Knowledge Hub\",\"url\":\"https:\/\/uptimerobot.com\/knowledge-hub\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2024\/04\/cropped-knowledge-hub-logo.png\",\"contentUrl\":\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2024\/04\/cropped-knowledge-hub-logo.png\",\"width\":2000,\"height\":278,\"caption\":\"UptimeRobot Knowledge Hub\"},\"image\":{\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/logo\/image\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/person\/c05598f15bcbd26ed4d53240dff2ae34\",\"name\":\"Laura Clayton\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2024\/04\/laura_clayton-150x150.jpeg\",\"contentUrl\":\"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2024\/04\/laura_clayton-150x150.jpeg\",\"caption\":\"Laura Clayton\"},\"description\":\"Laura Clayton has over a decade of experience in the tech industry, she brings a wealth of knowledge and insights to her articles, helping businesses maintain optimal online performance. Laura's passion for technology drives her to explore the latest in monitoring tools and techniques, making her a trusted voice in the field.\",\"sameAs\":[\"https:\/\/www.linkedin.com\/in\/laura-clayton-b00a4aa4\/\"],\"url\":\"https:\/\/uptimerobot.com\/knowledge-hub\/author\/laura\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Journalctl Explained: How To View And Analyze Systemd Logs - UptimeRobot Knowledge Hub","description":"Learn how to use journalctl to view, filter, export, and troubleshoot systemd logs. Includes advanced examples, automation tips and best practices.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/","og_locale":"en_US","og_type":"article","og_title":"Journalctl Explained: How To View And Analyze Systemd Logs - UptimeRobot Knowledge Hub","og_description":"Learn how to use journalctl to view, filter, export, and troubleshoot systemd logs. Includes advanced examples, automation tips and best practices.","og_url":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/","og_site_name":"UptimeRobot Knowledge Hub","article_published_time":"2026-02-16T10:59:01+00:00","article_modified_time":"2026-02-16T11:00:58+00:00","og_image":[{"url":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-1024x603.png","type":"","width":"","height":""}],"author":"Laura Clayton","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Laura Clayton","Est. reading time":"18 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#article","isPartOf":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/"},"author":{"name":"Laura Clayton","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/person\/c05598f15bcbd26ed4d53240dff2ae34"},"headline":"Journalctl Explained: How To View And Analyze Systemd Logs","datePublished":"2026-02-16T10:59:01+00:00","dateModified":"2026-02-16T11:00:58+00:00","mainEntityOfPage":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/"},"wordCount":3826,"publisher":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#organization"},"image":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#primaryimage"},"thumbnailUrl":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-1024x603.png","articleSection":["Logging"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/","url":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/","name":"Journalctl Explained: How To View And Analyze Systemd Logs - UptimeRobot Knowledge Hub","isPartOf":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#website"},"primaryImageOfPage":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#primaryimage"},"image":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#primaryimage"},"thumbnailUrl":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27-1024x603.png","datePublished":"2026-02-16T10:59:01+00:00","dateModified":"2026-02-16T11:00:58+00:00","description":"Learn how to use journalctl to view, filter, export, and troubleshoot systemd logs. Includes advanced examples, automation tips and best practices.","breadcrumb":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#primaryimage","url":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27.png","contentUrl":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2026\/02\/image-27.png","width":1080,"height":636},{"@type":"BreadcrumbList","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/journalctl-explained-how-to-view-and-analyze-systemd-logs\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Knowledge Hub","item":"https:\/\/uptimerobot.com\/knowledge-hub\/"},{"@type":"ListItem","position":2,"name":"Logging","item":"https:\/\/uptimerobot.com\/knowledge-hub\/logging\/"},{"@type":"ListItem","position":3,"name":"Journalctl Explained: How To View And Analyze Systemd Logs"}]},{"@type":"WebSite","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#website","url":"https:\/\/uptimerobot.com\/knowledge-hub\/","name":"UptimeRobot Knowledge Hub","description":"","publisher":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/uptimerobot.com\/knowledge-hub\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#organization","name":"UptimeRobot Knowledge Hub","url":"https:\/\/uptimerobot.com\/knowledge-hub\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/logo\/image\/","url":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2024\/04\/cropped-knowledge-hub-logo.png","contentUrl":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2024\/04\/cropped-knowledge-hub-logo.png","width":2000,"height":278,"caption":"UptimeRobot Knowledge Hub"},"image":{"@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/person\/c05598f15bcbd26ed4d53240dff2ae34","name":"Laura Clayton","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/uptimerobot.com\/knowledge-hub\/#\/schema\/person\/image\/","url":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2024\/04\/laura_clayton-150x150.jpeg","contentUrl":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-content\/uploads\/2024\/04\/laura_clayton-150x150.jpeg","caption":"Laura Clayton"},"description":"Laura Clayton has over a decade of experience in the tech industry, she brings a wealth of knowledge and insights to her articles, helping businesses maintain optimal online performance. Laura's passion for technology drives her to explore the latest in monitoring tools and techniques, making her a trusted voice in the field.","sameAs":["https:\/\/www.linkedin.com\/in\/laura-clayton-b00a4aa4\/"],"url":"https:\/\/uptimerobot.com\/knowledge-hub\/author\/laura\/"}]}},"_links":{"self":[{"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/posts\/1118","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/comments?post=1118"}],"version-history":[{"count":0,"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/posts\/1118\/revisions"}],"wp:attachment":[{"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/media?parent=1118"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/categories?post=1118"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/uptimerobot.com\/knowledge-hub\/wp-json\/wp\/v2\/tags?post=1118"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}