Gather logs for a support case
Collect octoja Asset Logs, agent log files, and browser logs from any device and attach them to a support case via the in-app support-tickets portal.
Written By Erdinc Akay
Last updated 26 days ago
When you contact octoja support, the right logs make the difference between hours of back-and-forth and a quick resolution.
octoja keeps two distinct log surfaces: an in-app activity log for each device, and the agent's own log files on the device itself. This article walks through both, plus the universal browser logs you can capture when reporting an issue with octoja in your browser. For an online device, octoja can package the agent log files for you with one click — for everything else, you collect what is relevant for the symptom you are reporting and attach it to your case.
What logs to send for which symptom
Different symptoms need different logs. Use this table as the starting point.
Send only the logs that match the symptom. The smaller the sample, the faster support can read it.
Capture asset logs from the device page
Every device in octoja has a Logs tab on its detail page. The tab shows recent activity that the server attributes to the device — completed agent tasks, remote actions a user triggered, and direct sessions such as a terminal. It defaults to the last 30 days, and you can narrow it with the time-range selector (Last 24 hours, Last 7 days, Last 30 days, or Last 90 days), the source and severity filters, and a content search box.
Open the Logs tab from any device:
Open Devices from the sidebar.
Click the row for the affected device.
On the device detail page, click the Logs tab.
The table has five columns:
To send these to support, take a screenshot of the Logs tab covering the period the issue happened, or copy the relevant rows into the message. There is no built-in export button.
Patch Management entries are written by the server when an agent reports patch-cycle results, and Deployment entries are written by the agent when it completes a software deployment. Both source types appear in the table whenever the corresponding activity has happened on the device.
If you prefer to query asset logs programmatically — for example to pull a wider time range or filter by source — see the Asset Logs API reference.
Collect the agent log files from the device
The octoja agent writes detailed log files on the device itself. These cover everything the agent does locally: starting up, talking to the octoja service, running monitoring checks, executing remote actions, and applying updates. They are the right place to look when telemetry is stale, when a check is failing in a way the Asset Logs cannot explain, or when a device has gone offline.
Online device: download the log files from the device page
If the device is online, you do not need to touch the device at all. On the device detail page, open the … menu in the top-right corner and choose Download logs. octoja fetches the log files straight from the agent and downloads them to your browser as a single .zip — it contains both the agent and the launcher log folders described below. Attach that zip to your support case.
The action is shown only while the device is online and requires the File Browser permission for the device. For offline devices — which is exactly when the launcher log matters most — collect the files manually as described next.
Offline device: collect the files manually
Agents log into a folder named logs next to the binary. Two binaries run on every device — the launcher (manages updates and supervises the agent) and the agent itself — so the device has two log folders.
Files are named Log.YYYY-MM-DD_NNN.log (with NNN rolling from 000 upward as a file fills up). A new file rolls every day, and any file that grows past 10 MB rolls to the next sequence number. octoja does not delete old log files, so you may see a long list — pick the file or files that cover the time the problem happened, plus one before and one after to give context.
For a problem that happened recently, the current day's Log.<today>_NNN.log from the agent folder is usually the most useful single file. If the device went offline or the launcher itself misbehaves, attach the launcher log too.
Reading these folders requires administrator rights on Windows or sudo on Linux and macOS.
Linux: stdout and stderr live in the system journal
On Linux the systemd service captures the agent's stdout and stderr in the journald journal. If the file logs do not show what you need, run the following on the device and attach the output:
sudo journalctl -u octoja-agent --since "2 hours ago" > octoja-agent.journal.logsudo journalctl -u octoja-launcher --since "2 hours ago" > octoja-launcher.journal.logAdjust --since to cover when the issue occurred.
macOS: launchd captures stdout and stderr to extra files
On macOS launchd writes the agent's stdout and stderr to dedicated files. They are usually empty, but if a startup problem prevented normal logging, attach them too:
/opt/octoja/data/logs/launcher.stdout.log
/opt/octoja/data/logs/launcher.stderr.log
/opt/octoja/data/logs/agent.stdout.log
/opt/octoja/data/logs/agent.stderr.log
Capture browser logs for browser-side issues
If the problem is with the octoja web app — a page does not load, a button does nothing, an error banner appears with no obvious cause — the browser's DevTools captures what we need: the console log (the messages your browser printed) and a HAR file (a recording of the network requests). Reproduce the problem with DevTools open, then export both — see your browser's documentation for exporting a HAR file and saving the console output. Attach both files to your support case; they include exactly what your browser saw, including any error responses from octoja.
The HAR file may include cookies and request bodies. Review it before sending if your environment requires you to redact sensitive headers.
Send everything to support
octoja exposes five intake channels in the header bar at the top of the page:
For a support case use the Life ring icon to open a support ticket. Describe what you observed and the time it happened (your browser local time is fine), and attach the log files you gathered above.
If your account does not show the Featurebase header buttons (some restricted environments hide them), reach out via community.octoja.de — see the Community Forum article for how the forum is organised.
Troubleshooting
The Logs tab shows "No logs recorded for this device." The device has not generated any server-attributable activity in the last 30 days. This is normal for a freshly enrolled device that has not yet run a remote action, terminal session, or completed task. The agent log files on the device itself will still contain entries — collect those instead.
The Logs tab fails to load. If telemetry on the device detail page works but the Logs tab errors out, this is likely a server-side issue worth reporting — capture the browser console as described above and include it.
I cannot open the agent log folder. On Windows, open File Explorer as an administrator, or run an elevated PowerShell and cd "C:\Program Files\octoja GmbH\agent\current\logs". On Linux and macOS, prefix the read with sudo.
The log file is too large to attach. Compress the day's log into a .zip before attaching. If a single file is many gigabytes, copy out only the lines around the time the problem occurred — most editors (Notepad++, VS Code, less, tail -n) can handle the file even when File Explorer cannot.
Before opening a case, check Product Status & Known Limitations for any current known issues that may match your symptom. The known-issues article is updated as soon as a problem is identified, and your symptom may already be tracked.