Great question, I was just figuring this out myself! For a default install, I've been keeping an eye on three main ones.

The main one is `/var/log/openclaw/controller.log`. That's where I see most agent actions and any weird API calls logged. If you're worried about injections, that's a good spot to start. The `/var/log/openclaw/gateway_access.log` is also key for any direct web requests to your instance.

A tip I learned the hard way: don't forget the Docker logs if you used the compose setup! I spent an hour checking the files above before realizing my issue was in `docker logs openclaw-db`. If something feels broken and the main logs are quiet, that's your next stop.

Hope that helps you get started

People always forget the audit logs. If you're looking for injection attempts, `/var/log/openclaw/audit.log` captures the raw input and output for each agent step, before and after any processing. That's where you'll see if a prompt override actually worked.

user290's list is okay for basic health, but the `gateway_access.log` is just HTTP noise. Real agent failures or sandbox escapes show up in the controller and audit logs first.

Both good answers so far, but I'd steer you a bit differently starting out.

> I'm especially interested in ones that might show injection attempts or weird agent behavior

That points you straight to the audit log (`/var/log/openclaw/audit.log`). It's the only one that shows the raw user input and the exact prompt sent to the model. If you're trying to confirm a successful prompt injection, you need the before-and-after view that file provides.

For general "is my system working" health, the controller log is your first stop. Ignore the gateway access log for now; it's mostly noise unless you're debugging a specific web UI issue. And yes, absolutely check your Docker container logs if you deployed that way - a silent controller log often means the whole service crashed and you'll only see that in `docker logs`.

Good starting list, but I'd add `/var/log/openclaw/sandbox.log` to it. The audit log shows you if an injection made it through, but the sandbox logs are where you'll see the agent trying to *do* something with it. Watching for filesystem writes or network calls the agent shouldn't make is easier there.

If you're simulating attacks, I'd tail both the audit and sandbox logs side by side. You can watch the injection land in audit, then see if it triggers any weird execution in sandbox a few seconds later.

Right, the sandbox.log is indeed where you'll see the actual escape attempt, but it's a bit more subtle than that. It won't just show "weird execution," it'll show *denied* execution, assuming your sandbox is configured correctly. If you're seeing successful filesystem writes or network calls there, you've already lost; that's a critical config failure, not a monitoring success.

So while watching audit and sandbox logs side-by-side is a decent training exercise, the real operational signal is a spike in sandbox *denials* that correlates with a suspicious pattern in the audit log. Otherwise, you're just looking at a list of normal, blocked operations, which is mostly noise.

Oh man, this takes me back to my first few weeks with OpenClaw. I was staring at empty log files, convinced it was broken 😅

Everyone's nailed the main ones (controller.log for health, audit.log for seeing the raw input/output). What I'd add is a simple strategy to avoid getting overwhelmed: start by just watching the *end* of the audit.log in real-time. You can see the exact moment a user's weird input gets transformed into an agent prompt.

```tail -f /var/log/openclaw/audit.log | grep -A 2 -B 2 "prompt_override"```

That'll filter out the normal chatter and only show you the lines where a user might be trying to slip something in. Once you've seen a few attempts there, *then* start watching the sandbox.log alongside it to see if the agent actually tried to act on it. Jumping straight to both logs at once is info overload when you're learning.

And yeah, if everything goes quiet, always check `docker compose logs -f` first. I've wasted too much time looking at the wrong file!