> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fetchhive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Logs

> Review workflow runs, filter activity by source and delivery, inspect traces, and debug callback delivery

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? <a href="#open-workflow-logs" id="open-workflow-logs" />

From the workflow editor, click **Logs** in the bottom control bar.

Or open **Workflows** in the sidebar and 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? <a href="#filter-workflow-logs" id="filter-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? <a href="#inspect-workflow-run" id="inspect-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 <a href="#traces" id="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:

* integration action name for connected-provider action steps
* 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? <a href="#inspect-output-and-webhooks" id="inspect-output-and-webhooks" />

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](../user-tracking/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](./publishing-and-versioning), [Callback Delivery and Webhook Triggers](./async-and-webhooks), and [Run with API](./run-with-api)