Skip to main content
Use log history in Fetch Hive when you want to review individual prompt, workflow, or agent runs and inspect what happened during a request.

​
Overview

Fetch Hive gives you separate log views for prompts, workflows, agents, and knowledge base processing. Each view starts with a table of runs, then lets you open a detail sheet for deeper trace and run-level inspection. These log views are for resource-level investigation. If you want to start from a tracked end user and then open their runs, see Filtering and drilling.

​
How do I open logs for prompts, workflows, or agents?

Open one of these sections in the main sidebar:
  • Prompts
  • Workflows
  • Agents
  • Knowledge Bases
Then click Logs in the secondary navigation. Fetch Hive opens the log table for that resource type. Prompt, workflow, and agent logs expose a Source section in the secondary navigation. Workflow logs can switch between All Sources, Dashboard, API, Scheduled, Webhook, and Agent. Prompt logs can switch between Dashboard, API, Webhook, and Experiment. Agent logs can switch between Dashboard, API, Webhook, Experiment, and Agent. If you already have a full request ID, paste the req_... value into global search and choose Go to request to open the request detail page directly.

​
How do I filter logs?

All three log pages use the date-range control in the header, pagination, and column visibility controls in the table. Each log page also has its own filter set:
  • Prompts logs support Provider, Model, API keys, and Prompt
  • Workflows logs support API keys, Workflow (dashboard workflows and workflow deployments), source navigation, and Delivery
  • Agents logs support Provider, Model, API keys, and source navigation
  • Knowledge Base logs support Knowledge Base, API keys, and Type
The Delivery filter on workflow logs lets you switch between All, Callback, and Direct runs. Source is what started the run; delivery is how the result came back. Some filter pickers also include an inline search field so you can quickly find a prompt or workflow in the list. Use Clear filters to reset the active filter set for the current log view.

​
What’s tracked

The log tables surface the main run fields you use during debugging and monitoring. Depending on the resource type, Fetch Hive shows combinations of:
  • Completion or run time
  • Resource name
  • Provider or model details
  • Tool usage
  • Status
  • Total cost
  • Total tokens
  • Duration
  • API key
  • Collaborator
Prompt logs include Total Tokens and Total Cost in the main table. Agent logs also include Total Tokens and Total Cost in the main table, along with a Tools column. Workflow logs focus on Tools, Total Cost, Duration, API Key, and run status. Knowledge base logs focus on Knowledge Base, Item, Type, Total Tokens, Total Cost, Duration, API Key, and run status.

​
How do I read a run detail sheet?

Click a row in the logs table to open the matching detail sheet. The sheet starts with a header that shows the request or run ID, the current status, and any live deployment badge when that run came from a deployment. Below that, Fetch Hive shows a summary strip with the most important run-level details, such as duration, cost, tokens, tool counts, owner, or charge type, depending on the run type. On the right side of the sheet, Fetch Hive shows the detailed content for the selected run or span. This can include response content, request details, inputs, metadata, and output sections. For model-backed prompt, workflow prompt, and agent spans, the detail panel shows the model stop reason when the provider reports one. This helps distinguish a normal stop from token limits, stop sequences, tool use, or content filtering. If a provider stream drops mid-response, Fetch Hive marks the run failed and keeps the partial response plus provider error in the log detail.

​
Traces

When a run has a trace, Fetch Hive shows a waterfall panel on the left side of the detail sheet. Use this panel to move through the run step by step. Selecting a span updates the detail panel so you can inspect that span’s timing and payload details. Some provider-reported phases do not include real timing boundaries; Fetch Hive shows those as structural markers with timing unavailable instead of treating them as zero-duration provider work. Span details can include:
  • Duration
  • Percent of total run time
  • Start and completion timestamps
  • API key
  • User
  • Metadata
  • Output
For prompt, workflow, agent, and knowledge base processing runs, this trace view is the fastest way to understand which part of a request took time, failed, or produced a specific output. Agent sub-agent spans keep their child_request_id so nested child runs can be opened individually and reconciled back into the parent trace even when the child finishes late or fails after partial work. OpenTelemetry is not the source of truth for this customer-facing trace view. OTel is an internal correlation layer that helps engineering follow a request across Rails, Sidekiq, Rust, Redis, SQL, and outbound HTTP. Fetch Hive trace rows and Analytics V3 continue to use product trace data.

​
Notes

  • Prompt and workflow logs support Source switching, but agent logs do not expose that navigation.
  • Workflow logs refresh running rows as status changes, and a running workflow row does not open the detail sheet until the run is no longer running.
  • The trace waterfall appears when the run has trace data available.
  • You can also open these same detail sheets from the Users section after drilling into a tracked end user.
See also: Credit Usage.