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

# Logs and troubleshooting

Open a workflow and select **Logs** to inspect its runs. Start here when a lead took an unexpected path, an action failed, or a meeting was not booked.

## Inspect a run

Select the relevant run and review its source, time, workflow version, and status. Then inspect the steps in the path taken.

For each step, compare its inputs, outcome, output, and any delivery details. Look for the first point where the actual result differs from what you expected.

| What you need to explain | Look for                                                                           |
| ------------------------ | ---------------------------------------------------------------------------------- |
| Wrong qualification path | Trigger answers, missing fields, Branch conditions, and rule order.                |
| Wrong assignee           | Rulebook inputs, matched rule, queue profile, member eligibility, and calibration. |
| No scheduler             | Source response mode, the path to Show Scheduler, and the returned response.       |
| No available times       | Host source, event settings, calendars, working hours, and required attendees.     |
| CRM record unchanged     | CRM step delivery, selected record, connection, permissions, and mapped fields.    |
| Message not sent         | Notification step outcome, destination, connection, and delivery response.         |
| Run waiting              | Scheduler window, Wait, human task, or pending provider delivery.                  |

## Understand unfinished runs

**Waiting** may be expected while the prospect books, a timer runs, a person responds, or an external operation finishes.

**Failed** means the run needs investigation. Review the error on the relevant step instead of changing unrelated routing settings.

**Needs reconciliation** means an external operation's result is uncertain. It may have succeeded in the provider even if Distro could not confirm the response.

## Recover an uncertain action

Check the provider for the expected record, message, or booking. Use the available reconciliation controls to record the confirmed outcome.

Do not blindly start a second run when the first may already have performed the action. That can create duplicate records or notifications.

Cancellation stops unfinished work where supported; it does not reverse a CRM write, sent email, or booked meeting.

## No run appears

Check the source's own submission or event first. Then confirm:

1. The correct workspace and workflow.
2. A published version and the workflow's On state.
3. The form or external connection's active version.
4. Caller access, authentication, and required input fields.
5. Workspace enrollment and execution availability.

For a website form, also check its original submission success and capture installation.

## Share useful details with support

Include the workflow name, approximate time, source, relevant run, expected result, and the step where the behavior changed. Keep secrets and unnecessary prospect data out of screenshots or copied payloads.

See [Routing logs and reports](/routing/logs-and-reports.md) for distribution and configuration history.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.distro.so/workflows/logs.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.