> ## Documentation Index > Fetch the complete documentation index at: https://docs.os.default.com/llms.txt > Use this file to discover all available pages before exploring further. # Run logs > Review every run of a workflow: what triggered it, the path it took, and why any step succeeded, warned, or failed. Every time a workflow runs, whether a form submission, a CRM change, or a manual test kicked it off, Default keeps a record you can review afterward. Run logs show you exactly what happened: which path the run took through the workflow, what each step did, and the full detail behind any warning or error. Open **Workflows**, select the workflow you want to inspect, then choose its **Logs** tab (next to **Graph**). The **Logs** tab appears on a workflow as this rolls out to your workspace. ## The runs list The **Logs** tab opens on a list of every run of that workflow, most recent first. ### Columns Each row shows: * **Version**: the published version of the workflow that ran, for example `v3`. If that's still the version currently published, the row also carries a **Current** badge. * **Record**: the person or company the run is about. The name comes first, for example `Jane Doe`, with the email or company domain underneath it, for example `jane@acme.com`. The icon next to it depends on what triggered the run: a contact icon for a form submission, a company icon for a CRM record trigger, and otherwise the record's logo, or its initials if none is found. If Default can't resolve a specific record for a run, this column shows a dash. * **Trigger**: what started the run, with an icon for the trigger type. * **Status**: one of **Success**, **Failed**, **Running**, **Suspended**, or **Pending**. A run that finished but logged at least one error along the way shows **Errors** instead of **Success**. A run you started manually to test the workflow also carries a **Test** badge. * **Timestamp**: when the run started. ### Search and filter runs Two different tools narrow this list, and they work differently. Type into the search box (placeholder **Enter node or action...**) to filter the rows already loaded on the current page down to ones mentioning that text, for example "enrich" to spot runs where an enrichment step ran or logged something. This only searches what's on screen, so it clears the page size and pagination controls while you're typing. Click the **Filter** button to add a real filter that asks the server for only the matching runs, which also works across every page: * **Status**: choose any of Success, Failed, Running, Suspended, or Pending, for example Failed and Suspended together to see every run that needs attention. * **Email**: matches contacts whose email contains the text you enter, for example `@acme.com` to see every run for one company's contacts. * **Record**: matches the same company or person label shown in the Record column, for example `Acme` to find every run touching Acme Corp. * **Date**: is between two dates, on or after a date, on or before a date, or in the last X days, for example the last 7 days. Add more than one filter and choose whether every condition must match or only one of them, then use **Clear all** to clear them all at once. If nothing matches your search or filters, the list shows **No runs match your filters**. If the workflow hasn't run yet at all, it shows **No workflow runs yet**. ### Move through pages At the bottom of the list, a page-size selector lets you show 20, 50, or 100 runs at a time, next to a "Showing X-Y of N" count. Use the previous/next arrows to move one page at a time, or type a number directly into the **Page** field to jump straight there. ## Open a run Click any row to open that run in detail. The view splits in two: the workflow's canvas on the left, the run's details on the right. ## The run canvas The left side is a read-only copy of the exact version of the workflow that ran. Default marks the trigger that fired and the path the run actually took through the workflow's branches, so you can see at a glance which route it followed. Any node the run logged a warning or error against carries a small count badge, for example 2 errors or 1 warning, in red for an error and amber for a warning. Click any node on the canvas to open its configuration exactly as it was at the time of the run. ## The run details panel The right side opens with a breadcrumb reading **Logs**, which takes you back to the runs list, restoring the exact page and filters you left it on. ### Run summary and sharing Below the breadcrumb, a summary card shows who or what the run is about and a **Share Log** button that copies a link straight to this run to your clipboard. If the run came from a scheduling trigger with a recording available, a **View Scheduling Replay** button appears alongside it. Expand **Trigger Details** to see the trigger itself, plus, when available, a **Triggered at** timestamp for exactly when it fired. For a CRM record trigger, this card also lists the provider, the object type, and the record ID involved. A form submission or an incoming webhook doesn't carry those extra rows here: its data shows up further down, under that step's **Show data**. ### Run timeline Below the trigger card, **Run Details** lists every step the run went through, in order, and a **Search** box lets you filter that list down to steps matching a name or message. Each step is labeled **Start** for the trigger or **Step** for everything after it, followed by the step's name. A step that logged a warning or error carries a count badge (for example 2 errors) and shows the time it ran; hover the time to see the exact duration. #### Show data Expand **Show data** under a step to see the exact values Default read or wrote, laid out as a **Field** / **Value** table. Click any row, or the clipboard icon that appears when you hover it, to copy that field name or value. Large objects and lists collapse into a compact preview you can expand into a tree and drill into, instead of one long line of text. For the trigger step at the top of the timeline, **Show data** shows only what actually fired the run: an incoming webhook shows just the body it received, and a form submission lists each submitted field as its own row, leaving out any UTM parameters that were left blank. #### Branch and condition steps A branching step in your workflow logs which branch it took and why. The summary tells you the branch by name and whether its conditions passed, or that no branch matched and the workflow fell through to its **Else branch selected** path. Expand the step to see the full condition breakdown underneath: every condition it checked, the value found in this run, and a **TRUE** or **FALSE** badge on each one, with AND/OR groupings called out so you can see exactly why the run went the way it did. #### Template variable errors If a step needed a value from an earlier step and that value wasn't there, the error tells you what was missing and where it should have come from, in plain language: for example, a "Create Contact" step couldn't run because it needed a company name from an earlier enrichment step, and that field had no value in this run. Expand **Show available fields** underneath to see what values actually were available to that step at the time. ## Access and rollout If a workflow hasn't been shared with you, opening its logs shows **Access required** instead, asking you to reach out to an admin or the workflow's owner for access. The **Logs** tab is rolling out workspace by workspace. If you don't see it yet on a workflow you own, check back soon or ask your admin.