# Logs, Tracing and Debugging — Dify Workflow Basics

Source: https://www.skillbyai.com/en/dify-workflows/o-debug

> See what every node did.

## Read the run, node by node

Each run is recorded with its inputs, every node's inputs and outputs, the rendered prompts, token usage, timings and errors. Use the editor's **step run** and single-node testing while building, and **logs** for production runs. When an answer is wrong, trace backwards: did the classifier route correctly? Did retrieval return the right chunks? Did the prompt render correctly? Did a code node fail? Dify can also send traces to external observability tools for deeper analysis. Dify's node names, menus and options change between versions; check the current Dify documentation.

## Run it reliably

Logs, cost awareness and a checklist turn a prototype into a dependable app.

![Three ideas: logs and debugging, cost, checklist.](assets/figures/dify-workflows/section-8-map.svg) — Figure 8.1 — Debugging, cost and checklist.

## A debugging order

Work from inputs to outputs.

```text
1 inputs: are start variables as expected (types, empty values)?
2 routing: which branch ran, and why?
3 retrieval: which chunks, with which scores?
4 prompts: rendered text correct, variables filled?
5 tools / HTTP / code: status codes, errors, outputs
6 output: end node variables, format
-> save the failing input as a regression test
```

## Keep a regression set

Save every input that once failed and re-run the set before each publish.

**Quiz:** An answer is wrong; what should you check early?

- [x] Whether routing and retrieval behaved as expected
- [ ] Only the font of the web app
- [ ] The number of API keys
- [ ] Nothing; republish

*Answer:* Whether routing and retrieval behaved as expected. Most failures start upstream of the LLM.