> ## 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 > Inspect Hive Agent run history, statuses, traces, nodes, costs, sources, and partial results Hive Agent logs show every workspace Hive Agent run in one table and let you inspect the run's trace, nodes, sources, budget ledger, and final response. ## How do I open Hive Agent logs? Open **Hive Agents** in the sidebar. Click **Logs** in the secondary navigation. Hive Agent logs use a workspace-wide run table and include **Source** navigation for **All Sources**, **Dashboard**, and **API** runs. ## How do I filter logs? Use the date-range control, pagination, column visibility, and table filters. Hive Agent logs support: * **Hive Agent** * **Status** * **Source** navigation for **All Sources**, **Dashboard**, and **API** * Text search by Hive Agent name, objective, or request ID The table includes **Hive Agent**, **Objective**, **Status**, **Pass**, **Nodes**, **Sources**, **Total Tokens**, **Total Cost**, **Duration**, **API Key**, and **Collaborator**. Hover the tokens, tasks, or cost totals to open the stage usage breakdown: one **Plan** row aggregates planner validation retries with nested **Attempt #1**, **Attempt #2**, and so on, while execute/verify node attempts keep their pass labels. ## What is the difference between pass and attempt? A **pass** is one full execute-and-verify round for the run. If one or more nodes are rejected, Hive Agents can start another pass for the work that still needs fixing. An **attempt** is a specific execute or verify try for an individual node. A node can show multiple attempts when it is executed, checked, rejected, and retried. In the Run Console, a node can show **Pending verification** after its execute attempt has completed but before the verifier has started. Retried nodes also move out of **Failed** while the run is actively executing or verifying them again on a later pass, using live attempt and pass data rather than the last stored failure row. **Compose attempts** are separate from node attempts. Compose attempts rebuild and check the final response after the required node work has already been verified. Example: if Pass 1 verifies two nodes and rejects one node, Pass 2 retries the rejected node. That retried node may show several attempts because each execute or verify try is recorded. ## Status glossary | Status | Meaning | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `pending` | The run has been created and is waiting to start | | `preparing_sources` | Fetch Hive is processing website or file sources before planning | | `planning` | The planner is turning the objective into nodes and verification criteria | | `executing` | Executor agents are working on nodes | | `verifying` | The verifier is checking node outputs | | `retrying` | Rejected nodes are being prepared for another pass | | `composing` | The composer is assembling and checking the final response | | `blocked` | The run hit a budget gate. Use `budget_block_state` to tell pauses apart: `awaiting_approval` means the workflow is waiting for a magic-link approval (`ended_at` is null); `stopped` means the run finished on budget (hard cap, or approval declined/expired) and `ended_at` is set | | `completed` | The run finished successfully, or finished best-effort with unverified nodes flagged | | `failed` | The run could not complete | | `cancelling` | Cancellation has been requested | | `cancelled` | The run stopped by cancellation | ## How do I cancel a running Hive Agent? While a run is active, open the **Run Console** from Hive Agent logs or open the run from **request detail** (global search, experiments, or the technical trace sheet). Click **Cancel run** in the sheet header and choose how to stop: * **Stop now** — stops immediately and marks remaining work cancelled * **Stop and keep verified work** — stops scheduling new work, lets in-flight steps finish, and keeps verified node output The status moves to `cancelling` while the run drains, then `cancelled` when finished. See [Troubleshooting — cancelled](./troubleshooting#cancelled) for hard-stop vs partial-result behavior. ## How do I read the detail sheet? Click a run row. The root run overview keeps the final response, source list, node overview, budget ledger, and run config together. The final response prefers the accepted composed response when one is available. Verified node outputs remain available as supporting detail. In best-effort mode, unverified nodes stay flagged so you can see what did not pass. Node details can show output, rejection reasons, verification checks, pass number, cost, tokens, and linked child AgentRun details. The Run Console shows separate banners for **awaiting approval** (you can approve to continue) versus **stopped on budget** (the run is finished). The stopped banner uses the blocking gate event when available: it distinguishes spend that already hit the cap from blocks where the next step's projected cost would exceed the cap, and it uses the cap recorded at block time rather than a later blueprint value. Budget spend in the console uses `cumulative_cost_usd` — the same figure `BudgetGate` enforces — not the plan-time `projected_cost_usd` estimate. ## How do traces work? Hive Agent traces show the loop as a waterfall: * Source preparation * Planning * Execution * Verification * Repeat decisions * Compose attempts * Budget checks and budget events * Retryable stage errors * Final completion, failure, or cancellation Compose spans appear as soon as composition starts, not only after the composer finishes. While a compose attempt is running, the run status is `composing` and `run_config.composition.status` is `running`. Execute and verify spans also appear while each node stage is running (`status: running`), then complete on the same span row when the stage finishes. Execute, verify, compose, and compose verify are sibling root-level spans; imported child AgentRun details stay nested under their own stage anchor. The waterfall orders spans by lifecycle phase and pass (`order_pass`, `order_phase`, node position, execute-before-verify), not wall-clock start time alone — so prepare, pre-plan budget gates, plan, per-pass budget gates, execute nodes, verify nodes, compose, compose verify, and terminal spans stay readable even when child traces finish at different times. Compose stage spans keep the full attempt envelope while imported composer child spans are scaled to fill that window. Budget spans (`agent_task.budget_gate_check`, `agent_task.budget_step_cost`, `agent_task.budget_threshold_crossed`) are semantic markers anchored to stage start or end — not separate work units. Per-node execute gates nest under their `execute_node` row; step costs and threshold crossings appear at the end of the stage envelope. Pass-level gates stay at the root but align to the earliest execute in that pass. When verify fails before semantic checks (for example `failure_reason: no_execute_attempt`), the verify span input includes `wired_execute_attempt_id` from the workflow handoff for debugging. Execute and verify stage span metadata also carries `stage_pair_key` (`{node_id}-p{pass}-a{attempt}`), `paired_span_id` (the counterpart span id), and `verify_attempt_id` on the execute row after verify finishes. Older traces can backfill these fields via `agent_tasks:repair_trace_lifecycle`. Select a stage to see its **Input**, **Output**, and **Metadata**. Failed, blocked, or retryable stages show an issue alert. Budget spans show budget settings in the span header, and repeat spans show repeat settings there. A run-level failure message appears on the run overview and terminal spans, while allowed budget checks stay informational. Planner, executor, verifier, and composer calls can expand to show their child AgentRun trace inline, including model reasoning, LLM responses, and tool input and response panels. Use the child request link when you need to open that exact run separately. ## What happens after partial-result cancellation? A partial-result cancellation stops new node work, lets already-started node work drain, and stores verified node output in the run details. The run status is still `cancelled`, but the verified partial result remains available from the detail sheet. See also: [Log History](../monitoring/log-history) and [Troubleshooting](./troubleshooting).