Analytics and Logs

DocsGPT records every chat, API call, scheduled run and webhook run. You can review them in two places:

• Settings → Analytics and Settings → Logs (under Insights) cover your account.
• An agent’s Logs tab covers that one agent: the same charts, its guardrail activity and its logs.

For a readable list of what your automations did (scheduled, webhook and workflow runs, background jobs and monitor wakes), use Activity → History; Logs stays the full technical record.

For metrics and traces sent to an external backend such as Grafana or Honeycomb, see Observability. Admins can see usage for the whole instance under Admin → Usage (see Admin dashboard).

Who sees what

The agent’s Logs tab is open to the owner and editors. Viewers see it only when the owner turns on Viewers can see logs in the agent’s share dialog (see Teams and sharing).

Analytics

Pick a period in the top-right corner: Hour, 24 Hours, 7 Days, 15 Days or 30 Days (the default). The last hour is charted per minute, the last 24 hours per hour, and longer periods per day. Times are in UTC.

If an admin has set a usage quota for you, Your usage quota at the top shows your tokens and cost against the limit, split into Chat without an agent and Through agents when both apply, with the time it resets. It doesn’t appear when you have no quota, or on an agent’s tab.

The summary cards total the period:

The charts below them:

• Messages: questions per interval.
• Token Usage: Prompt Tokens and Generated Tokens per interval. Group by splits the bars By model, By agent (not on an agent’s tab) or By flow, which is what the tokens were spent on, such as chat, a scheduled run or a graph build. More than five groups fold into Other. Background tokens adds tokens spent outside a user’s request, such as title generation, history compression and query rephrasing; it’s off by default.
• Scheduled Runs: Completed, Failed and Skipped runs of agent schedules per interval.
• Tool Usage: Successful and Failed calls for each tool.
• User Feedback: Positive Feedback and Negative Feedback per interval.

Logs

The Logs list shows the newest entries first and loads more as you scroll. Runs are placed at the time they started. A run that is still going (an answer being written, a scheduled, webhook or workflow run) is listed as running, with how long it has run and, for a workflow, the step it is on. The list updates on its own: when the run ends, its finished entry replaces it. An answer being written also says who asked: API for calls through the API, Shared for someone using a shared agent, Chat for a chat in the app. Narrow the list with:

• the level: All levels, Info, Warning or Error;
• the event type: Chat, Scheduled, Webhook, Workflow, System (request errors), Search (the Search API and MCP search_docs) or Graph build, or Liked and Disliked for answers rated that way;
• Search logs…, which matches the entry’s summary, usually the question.

Each row shows the time, the event type, the action, how long it took and the summary, colored by level. Click a row to expand it. What it holds depends on the type:

• Chat: the agent, the visitor’s like or dislike, the passthrough values the request carried (such as user_id=emp-42), the answer, the tool calls and the sources used. A rated answer also shows a thumb in its row.
• Scheduled: the status, what triggered it, the error type, tokens, duration, the conversation the run wrote to, the instruction and the output.
• Workflow: the workflow, its status, duration, steps and result.
• Webhook and System: the endpoint and the error or activity details.

Copy copies the entry as JSON, without its id, action, timestamp and event type.

Execution traces

An entry with a recorded trace shows View trace when expanded, with a short summary: the number of LLM calls, tokens in and out, tool calls, retrieval time and errors. A chat turn that paused for a tool approval has one trace per round, and the button says how many (View trace (2 rounds)).

View trace opens Execution trace, a waterfall of every step: agent runs, LLM calls, tool calls, retrieval, vector searches, embeddings, reranking, guardrails and workflow steps, each with its duration and status. Click a step to see its details, such as the provider and model, input, output and cached tokens, time to first token and cost for an LLM call; the arguments and result for a tool call; or the query, top score and retrieved chunks for a search.

Traces keep short previews, not full prompts, and are deleted after 30 days by default. Operators set what is recorded and for how long; see Execution traces.

Guardrail activity

An agent’s Logs tab also has Guardrail activity: every guardrail check that blocked, redacted or flagged content on that agent, and every check that couldn’t run. Filter it by check and outcome, and choose how many days to show.

API

The same data is available over the API, scoped the same way, with an agent’s id as api_key_id to limit it to that agent: POST /api/get_message_analytics, /api/get_token_analytics, /api/get_feedback_analytics, /api/get_tool_analytics, /api/get_schedule_analytics and /api/get_user_logs, and GET /api/traces. A personal access token needs the analytics:read scope. See the REST API reference.

/api/get_user_logs takes the list’s filters and a few more. Chat rows carry conversation_id, passthrough and feedback ({"text": "like" | "dislike", "timestamp"}):

Let an agent review the logs

An agent can read these logs through an API tool, for example to report the most common complaints every morning:

1. Create a personal access token with analytics:read, plus conversations:read if the agent should open whole conversations and agents:read if it should look up agent ids. Leave it unrestricted: a token limited to some agents can’t read logs.
2. In Token created, select Create tool for agents. This adds an API tool named DocsGPT API (token name) with the endpoints the token can read: list_agents, get_logs, get_feedback_counts, get_message_counts, get_conversation and get_trace. The token is stored, encrypted, as the tool’s Authorization header.
3. Add the tool to an agent, give it a schedule such as “Read yesterday’s disliked answers of the Support bot and list the three most common problems”, and a tool to report through, such as Telegram or an MCP server for your issue tracker.

The tool calls the API at the address this web app uses. Agent tools can’t call localhost or private IP addresses, so on an instance reached at such an address the button reports that agents can’t reach it and creates nothing. To avoid reporting the same problem twice, have the agent keep notes of what it reported with the memory tool.