Drop in any log output — kernel panics, nginx errors, systemd failures, OOM events, auth logs. Diagnose multiple sources at once, stream results live, ask follow-up questions.
Drop in log output from a kernel panic, a failing systemd unit, an nginx error log or an OOM event, and an AI model explains what went wrong and how to fix it. You can analyse several sources together and ask follow-up questions. It uses your own API key with Anthropic, OpenAI, Google Gemini or Azure; the key is saved only in this browser and sent only to the provider you choose.
The lines around the failure, not the whole file. Useful sources are journalctl -u SERVICE -n 200 --no-pager, journalctl -k -b -1 for the kernel log of the previous boot, /var/log/nginx/error.log and dmesg -T. Include a minute or two before the error so the cause is in view.
Logs often contain IP addresses, hostnames, emails and tokens. Run them through the Log Scrubber first to replace those, and check your provider’s data policy. Nothing is sent to MYSYSAD; requests go straight from your browser to the provider you pick.
You pay the provider directly for what you use, choose the model, and keep control of the data relationship. The page doesn’t proxy your requests through any other server.
journalctl -b -1 shows the previous boot, if the journal is persistent (/var/log/journal exists). last -x | head shows recent shutdowns and reboots, and an abrupt end to the previous boot’s log often points to a power loss or kernel panic.
Yes, but the OOM Killer Autopsy does it without AI: paste the kernel’s OOM report and it shows which process was killed, what was using the memory and how to prevent it.
Related tools: Log Scrubber · OOM Killer Autopsy · Error Message Decoder · All tools A–Z