> For the complete documentation index, see [llms.txt](https://docs.pipekit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pipekit.io/using-pipekit/runs/workflow-logs.md).

# Workflow Logs

The Workflow tab shows your run as a hierarchical table: every step with its status, duration, pod names, output artifacts, error messages, and resource duration.

## Collapse children by default

Large workflows can produce hundreds of rows once every per-stage scaffolding step (`lock-cache`, `await-image`, `clone`, …) is expanded. Mark a template as a logical stage and Pipekit will render its direct children collapsed by default — users still expand and re-collapse freely.

Add this annotation to the template that declares the `dag:` or `steps:` body:

```yaml
metadata:
  annotations:
    workflows.pipekit.io/ui-collapsed: "true"
```

Any value other than the case-sensitive string `"true"` (missing, empty, `"false"`) keeps the default expanded behavior.

### Failed runs expand to show the failure

The annotation never hides a failure. When the table mounts, Pipekit expands every stage on the path from the workflow root down to each `Failed` or `Error` node, even if that stage is annotated `ui-collapsed: "true"`. So a failed run opens with its failures visible, and you do not have to hunt through collapsed stages to find what broke.

This happens once, at mount. From there collapse state follows only your own clicks — a stage that fails later in a live run will not re-expand a row you have since collapsed.

## Where the annotation can live

The annotation is resolved identically whether the template is:

* declared inline in `workflow.spec.templates`,
* declared in a `WorkflowTemplate` referenced via `templateRef`,
* declared in a `ClusterWorkflowTemplate` referenced via `templateRef`, or
* reached through a chain of refs up to ten levels deep.

Put it on whichever template you own that declares the stage.