Logs

Workflow logs help you inspect what happened after a run starts, whether that run came from the dashboard, API, schedule, webhook trigger, or agent. Use this page to review recent workflow activity, filter the runs you care about, and open a run detail sheet with trace data and output.

​

Overview

The workflows logs UI is a table-driven view under Logs in the workflows section. It supports source filtering from the sidebar, date range filtering from the header, and row-level inspection through a detailed run sheet. When you open a completed run, the detail sheet combines summary data, a trace waterfall, request details, output, start inputs, and callback delivery information when present.

​

How do I open workflow logs?

Open Workflows in the sidebar. Click Logs in the workflows section menu. Use the Source group in the sidebar when you want to switch between All Sources, Dashboard, API, Scheduled, Webhook, and Agent. Use Dashboard when you only want runs started from the editor or dashboard UI. Use API when you only want runs started from a workflow deployment through the public API. Use Scheduled, Webhook, and Agent for runs launched by those origins.

​

What can I filter in workflow logs?

Use the date range control in the header to choose a custom range or an available preset. Presets include ranges such as the last one, seven, 30, or 90 days, but longer ranges may require a plan with more log history. Use API keys to narrow the table to runs started with one or more workspace API keys. Use Workflow when you want to isolate runs for a single workflow. Use Delivery to switch between All, Callback, and Direct runs. Delivery is separate from source: an API invoke run can use callback delivery, while webhook-triggered runs always use callback delivery. Use User metadata to filter by a tracked metadata property. Choose a property key to find runs where that key exists, or add an exact value to match scalar values such as cus_123, enterprise, true, or 12. Click Clear filters to reset the active filter state.

​

What’s tracked in the workflow logs table?

The main logs table shows summary fields for each run, including:

• Completed At
• Name
• Tools
• Status
• Total Cost
• Duration
• API Key
• Collaborator

For live runs, the Name column can also show the deployment variant badge, including the variant name and version number. The Tools column reflects the providers or step sources that contributed real work completions to the run. Workflow orchestration records, such as parallel step aggregation, are excluded from this summary even though they can still appear in the trace timeline.

​

How do I inspect a workflow run?

Click a completed row in the logs table. Fetch Hive opens a run detail sheet on the right. The header shows the run ID, status, start time, deployment variant badge when present, a source badge such as Scheduled or Webhook, and a Callback badge when the run uses callback delivery. The summary strip below shows the workflow, duration, cost, tools, and owner for that run. If the workflow still exists and is not archived, the workflow name in the summary strip links back to the workflow editor.

​

Traces

Use the trace waterfall on the left side of the run detail sheet to understand how the run progressed over time. Each span helps you inspect a specific part of the run, such as the incoming request, workflow start, tool activity, LLM activity, and workflow completion. When you select a span, the right side updates to show the span details and any linked completion data. Depending on the selected span, this can include:

• model response data
• request details
• start inputs
• output content
• user metadata
• metadata
• token and cost breakdowns

For Claude AI prompt completions, request details can include Prompt Cache, which is the configured Anthropic prompt-cache TTL assigned to that step run. Actual cache reads and writes are still shown through the cached-token usage fields. This is the main debugging view for workflow runs. Start here when you need to understand which part of the workflow was slow, failed, or produced the wrong result.

​

How do I inspect output, callback delivery, and webhook logs?

Open a run from the logs table. Select the request or completion spans in the trace panel to switch the right-side details. Use the output section when you want to inspect the final workflow result from the workflow.complete span. Copyable log cards include controls to copy the displayed content or minimize the card while you compare other run details. If the run uses callback delivery, the request-level details can also show Callback delivery with the callback URL used for that run. If webhook delivery logs are present, the same sheet can show Webhook Logs with callback URL, retry count, response code, payload, response body, and a Retry action for failed callback delivery attempts. Webhook logs are delivery attempts, not the run source.

​

Notes

• The logs table updates in response to workflow run status changes, so recent runs can refresh while you are viewing the page.
• Fetch Hive tracks user metadata property names over time from workflow invokes so the metadata filter can suggest keys your workspace has actually sent. See Invoke metadata for request examples.
• Running rows are not the main entry point for deep inspection. Open a completed run when you want the full detail sheet and trace view.
• Callback delivery details are only visible when the selected run actually used callback delivery.
• Source tells you what started the run. Delivery tells you whether the run waited for a direct response or returned immediately for callback delivery.

See also: Publishing and Versioning, Callback Delivery and Webhook Triggers, and Run with API