The system permanently records what it does in logs. When something does not work, that is where the explanation is: which service failed, when, and why.
Everything is gathered in one place, whichever service is involved: a single command, journalctl, lets you read it all.
You do not need to understand everything. Spotting the moment of the problem and copying the few matching lines is more than enough to ask for help.
This page is used over SSH (see SSH access).
journalctl -f
Lines appear as the system writes them. This is very handy to reproduce a problem: run this command, trigger the malfunction, and watch what appears.
Press Ctrl + C to stop the display.
journalctl -u SERVICE_NAME
To find a service name, see the Services page.
Add -f to follow that service live:
journalctl -u SERVICE_NAME -f
Logs are large. To see only what happened recently:
journalctl --since "1 hour ago"
journalctl --since today
journalctl --since "2026-07-25 14:00"
And to keep only errors:
journalctl -p err --since today
To see what happened during the last boot:
journalctl -b
And during the previous boot, useful when the machine restarted on its own:
journalctl -b -1
To send logs to the forum or to a bug report, save them into a file:
journalctl -b > /tmp/journal.txt
Then fetch that file onto your computer:
scp root@YOUR_SERVER_ADDRESS:/tmp/journal.txt .
Always state the approximate time at which the problem happened: that is what makes it possible to find the right lines in a log containing thousands of them.
Read what you publish: logs can contain addresses, device names, sometimes credentials. Remove anything you do not want to make public.
Nothing special to remember: services running in containers write to the same journal as the rest of the system. The command shown above works for them identically:
journalctl -u zigbee2mqtt
See Services and modules.
By default the Calaos server only records the essentials. When hunting for the cause of a specific problem, you can ask it to be far more talkative:
calaos_config set debug_enabled true
calaos_config set debug_level 4
systemctl restart calaos-server
You can also target a particular area, to avoid drowning in messages. Each area gets its own level:
calaos_config set debug_domains ota:5,remote_ui:5,remoteui:5
Set this back to false once you are done diagnosing. Detailed logs fill the disk quickly, and make ordinary logs much harder to read.
calaos_config set debug_enabled false
systemctl restart calaos-server
These settings are listed on the calaos_config page.
Logs are stored in /var/log, which is excluded from restore points. Concretely: after a rollback, the logs of the incident are still there, and you can still understand what happened. See Under the hood.
To know how much space the logs take, and reduce it if needed:
journalctl --disk-usage
journalctl --vacuum-time=30d