Monitoring and Logging AI Agent Activity

An AI agent that fails, loops, runs up unexpected costs, or gets tricked by a malicious input doesn't announce it. If you're not looking at logs, the first sign of trouble is usually a customer complaint, a surprise bill, or a security incident you're reconstructing after the fact instead of catching in progress. This article covers what's actually worth logging, then where to find that record across the AI app catalog: full detail for n8n, OpenClaw, and NanoClaw, and a quick-reference for the rest.

Why This Matters More With Agents Than With Regular Apps

A traditional app either works or throws an error. An agent can "work" in the sense that it ran without crashing, while still doing the wrong thing: calling the wrong tool, looping on a failed action (covered in our repetition and loop issues article), or acting on a malicious instruction smuggled in through an exposed endpoint (covered in our webhooks and API security article). None of that shows up as a crash. It shows up in the log of what the agent actually did, which is why "it's running" isn't the same as "it's behaving."

What's Actually Worth Looking At

• Execution or session history — a record of each run: what triggered it, what it did, and whether it succeeded or failed.
• Tool calls — which specific tools or APIs the agent invoked, and with what arguments, not just that "a tool ran."
• Errors and retries — not just that something failed, but whether it kept retrying, and how many times.
• Token and cost usage — a sudden spike is often the first visible sign of a loop or an abused endpoint, well before anything else looks wrong.

Monitoring n8n

n8n keeps two separate kinds of records, and it's worth knowing both exist.

Executions (What Your Workflows Actually Did)

Every workflow run shows up in the Executions list in the n8n editor, with its status, how long it took, and the data that passed through each node. This is saved by default, controlled by a few environment variables:

• EXECUTIONS_DATA_SAVE_ON_SUCCESS (default all) and EXECUTIONS_DATA_SAVE_ON_ERROR (default all) — whether execution data is kept for successful and failed runs.
• EXECUTIONS_DATA_PRUNE (default true) — whether old execution data gets cleaned up automatically.
• EXECUTIONS_DATA_MAX_AGE (default 336 hours, 14 days) and EXECUTIONS_DATA_PRUNE_MAX_COUNT (default 10000) — how long execution data is kept before it's pruned, whichever limit is hit first.

Application Logs (What n8n Itself Is Doing)

Separate from execution history, n8n also logs its own internal activity using the Winston logging library. Set the level and output with:

Replace youruser with your actual username on the server, and adjust the rest of the path if you'd rather store the log file somewhere else.

Log levels range from error (least verbose) to debug (most verbose); info is a reasonable default for normal operation, reserving debug for active troubleshooting since it also logs HTTP request bodies and credential resolution.

Monitoring OpenClaw

OpenClaw's gateway writes a rotating JSONL log file by default at:

This is a default location, not something you type — YYYY-MM-DD is filled in automatically with the current date by OpenClaw itself, so there's nothing to replace here.

Each file rotates at 100 MB by default, keeping up to five numbered archives before older ones are removed. Each line is a structured JSON object, and includes machine-filterable fields like agent_id, session_id, and channel when relevant, so you can filter for a specific agent or conversation rather than scanning the whole file.

Reading the Logs

Live-tail the gateway's log over RPC:

To filter to just one messaging channel's activity:

Replace whatsapp with the actual channel you want to filter to, such as telegram or discord.

The Control UI's own Logs tab tails the same file if you'd rather read it in a browser than a terminal.

Log Levels and Redaction

File logs and console output can be set to different verbosity levels independently (logging.level for the file, logging.consoleLevel for the console), or overridden for a single run with the OPENCLAW_LOG_LEVEL environment variable or the --log-level flag. OpenClaw also redacts common secret values (API keys, tokens) from log content by default (logging.redactSensitive: "tools"), though this redaction is best-effort and applies to message text rather than every possible field.

Monitoring NanoClaw

NanoClaw splits its logging across a few different files and databases, depending on what you're trying to answer:

Since NanoClaw runs each conversation in a container with --rm, the container's own filesystem is gone once it exits. There's no persistent in-container log to go back and check; if an agent failed silently inside a container, the host app log and the session databases are what you have left to reconstruct what happened.

For more detail, including streamed container output, raise the log level:

Quick Reference: Other AI Apps

For the rest of the AI app catalog, here's where to find the equivalent activity record for each, confirmed against each project's own documentation where available.

Dify

Every Dify app has a built-in Logs page in its left-hand navigation, recording every interaction whether it came through the web app or the API. For metrics over time (requests, tokens, latency by app or tenant), Dify's own repository includes a ready-made Grafana dashboard that reads directly from Dify's PostgreSQL database.

Langflow

Langflow's Traces feature is enabled by default and needs no setup: every flow run is recorded as a trace, with a span for each component showing its inputs, outputs, latency, and token usage where available. View them in the UI under the flow's Traces tab, or retrieve them programmatically from the /monitor/traces API endpoint. For exporting this data to an external observability stack (Grafana, SigNoz, and similar), Langflow ships with built-in OpenTelemetry support that only needs an OTLP endpoint configured, no additional instrumentation.

Claude Code

Claude Code writes a full session transcript for every conversation as JSONL under ~/.claude/projects/<project>/<session>.jsonl, including every tool call, file read/edit, and per-turn token usage. The terminal itself now shows fairly condensed summaries by default rather than full detail; running with --verbose shows considerably more, though as raw, unformatted JSON. Several open-source tools exist specifically to read these transcripts in a more structured, searchable form when the terminal's summarized view isn't enough.

Ollama

Ollama's own server log is the main thing to check when something isn't behaving as expected, and where you find it depends on how it's running:

That's the command for a systemd-managed Linux install (the most common case on a VPS). If Ollama is running in a container instead, use docker logs <container-name>.

Paperclip

Paperclip has a built-in Activity Log, confirmed from its own official documentation: a permanent, complete record of every event in your deployment — every task status change, comment, agent hire or pause, budget spend, and approved proposal — each with a timestamp and the name of whoever (or whatever) caused it. Unlike per-run agent transcripts, which are stored per run and can scroll off over time, Activity Log entries are kept permanently, specifically so you can audit what happened months later.

Sim

Sim has one of the more thorough built-in logging systems of any app in this list, confirmed from its own official documentation. Every workflow run, however it was triggered (manually, via API, Chat, Schedule, or Webhook), is recorded on a dedicated Logs page with filtering by time range, status, trigger type, folder, and workflow, plus a live mode for real-time updates. Clicking into any run shows a full block-by-block breakdown: each block's input and output, a timeline of execution, and a token/cost breakdown per model call. Sim also saves the workflow snapshot behind each run, so you can open the exact blocks and configuration that were active at the time, even if you've since edited the workflow. Retention is 7 days by default, upgradeable for longer. A CLI is also available for scripted access:

--limit 50 is just an example — adjust the number to however many recent runs you want to see, or drop the flag entirely for the default.

Add --trace to sim logs get <runId> for expanded trace spans with inputs, outputs, errors, timing, and cost for a specific run — replace <runId> with the actual run identifier shown on the Logs page.

Hermes Agent

Hermes Agent automatically saves every conversation, across every platform it's connected to (CLI, Telegram, Discord, Slack, WhatsApp, email, and others), as a session. This is tracked in two places at once, confirmed from Hermes Agent's own official documentation: a SQLite database (~/.hermes/state.db) holding structured, full-text-searchable session metadata (model used, token counts, timestamps, full message history), and raw JSONL transcripts (~/.hermes/sessions/) that include the actual tool calls made during the conversation.

GatorClaw

GatorClaw's own product page lists Real-Time Monitoring as a built-in feature: tracking workflow activity and performance from a centralized dashboard. Since GatorClaw is built on the same underlying ecosystem as OpenClaw, the structured JSONL logging covered earlier in this article's OpenClaw section applies underneath it as well; the dashboard is GatorClaw's own guided layer on top of that.

BMAD

BMAD isn't a standalone running service, it's a workflow method that installs directly into an AI coding tool you already have, such as Claude Code, via npx bmad-method install. Confirmed from BMAD's own official repository: there's no separate BMAD process, server, or dashboard described anywhere in its documentation, so it doesn't keep its own activity log. Whatever it does shows up in the logs of the underlying tool it's layered onto, covered elsewhere in this article for Claude Code.

A Few General Practices

• Check logs on a schedule, not just when something breaks. A quick look for repeated errors or unusual activity, even weekly, catches problems long before a customer does.
• Know your retention window. Each app prunes old data differently; if you might need to investigate something after the fact, make sure the relevant log or execution history is actually still around by the time you go looking.
• Treat a token or cost spike as a signal, not just a bill to check later. It's often the first visible symptom of a loop (see our repetition and loop issues article) or an abused endpoint (see our webhooks and API security article), often showing up before any error does.
• Any dashboard or log viewer you expose as a web UI needs the same access controls as anything else on your server. A monitoring tool that's easier to reach than the agent it's watching defeats some of the point of watching it.

Summary

An agent that's running isn't the same as an agent that's behaving, and the difference only shows up in what it actually logged. n8n, OpenClaw, and NanoClaw each keep their own detailed execution or session records, covered in full above. Across the rest of the catalog: Dify and Sim both have dedicated Logs pages in their UI (Sim's is genuinely one of the most thorough of any app here), Langflow's Traces are on by default with no setup needed, Paperclip keeps a permanent Activity Log distinct from its scrollable run transcripts, Hermes Agent tracks every conversation as a searchable session, Claude Code and Ollama each write their own session or server log, GatorClaw adds a real-time dashboard on top of OpenClaw's own logging, and BMAD simply shows up in whichever tool it's layered onto. Checking these on a regular cadence, and treating a cost or token spike as an early warning rather than an afterthought, is what turns logging from a debugging afterthought into something that actually catches problems while they're still small.