# Step-Level Executions > Inspect the history, inputs, and outputs of individual steps using the Executions tab. Step-Level Executions answers: **What entered and left this Step, and how did each attempt end?** Start in [Activity](/manage/workspace-settings/activity) for workspace-wide monitoring or the [Execution Log](/build/the-canvas/execution-log) for one workflow's run, then come here once you know which Step needs attention. --- ## Finding the Executions tab When you want to see if a step ran successfully or inspect its data payload: ![A step selected on the canvas with its Executions tab open, listing one run from nine hours ago with its id and a link to open it.](/images/docs/canvas/executions-panel.webp) *Every run of the selected step, newest first. Expand one to see what went in and what came out.* ### Select the Step Click on the step directly on the canvas. ### Open the App drawer The drawer opens on the right side of the screen. ### Switch to Executions At the top of the App drawer, click the **Executions** tab. ### Start from the whole run If you do not yet know which Step needs attention, start in [Activity](/manage/workspace-settings/activity). It shows the whole-run timeline across workflows and lets you open the affected workflow on the canvas. **Workflow data** answers a different question: where a value came from and where it goes. Use it when a field arrives empty downstream and you need to find the connection it stopped travelling along. See [Steps and Connections](/build/core-concepts/steps-and-the-canvas). --- ## Inspecting input and output The Executions tab lists the history of every time that specific step was executed. Each entry shows a timestamp, the status (Success, Error, or Pending), the execution id, and the data the step produced. Expand an entry and the output is there as a JSON tree. ### Reading multiple entries for one run A single run can legitimately produce several entries. A step in [Run for each item](/build/action-steps/loops) mode writes one per item. A step merging parallel branches writes one per incoming branch, and a loop writes one per iteration. Entries that are genuinely **retries** carry an **Attempt 2**, **Attempt 3** marker, each with its own error and timestamp. Where Glow knows how many attempts the step is allowed, the marker names the total too: **Attempt 2 of 11**. A first attempt is never marked, so any entry without one ran on its own. See [Retry on fail](/build/core-concepts/error-handling#retry-on-fail) for how to enable retries. ![A step's Executions tab showing one HTTP Request step failing four times in a row — the first with no marker, then Attempt 2, Attempt 3 and Attempt 4 — each stamped a few seconds apart with the same 404 error message.](/images/docs/canvas/retry-attempts.webp) *A step with Max retries set to 3 runs four times in total. The gaps between the timestamps are the fixed wait, not a growing backoff.* ### How long a run is kept Runs are kept for **30 days** after completion by default. One window covers: - The workspace [Execution log](/build/the-canvas/execution-log). - Step-level records and input/output payloads. Each run preserves the retention policy active when it executed. The **Execution ID** on an entry identifies the run for debugging and support requests. Thirty days covers debugging and a monthly review, not an audit trail. If a workflow matters enough that you would want a record of it later, send what you need out of Glow while the run is happening: an [HTTP Request](/build/action-steps/http-request) step to your own logging, or a message to the channel your team watches. A longer window for your workspace is something to raise with your account team. See [System Limits](/reference/system-limits#data-retention). **The output you see is the shape you reference downstream**, wrapper and all. An HTTP Request's response arrives under `ret`, so what you see is `{"ret": {"id": 1}}` and the reference is `{{ 3.ret.id }}`. Reading it once beats guessing the path from an API's own documentation. The **Test & Debug** tab shows the same thing for a run you start by hand with test data. **To see what went into a step**, look at the output of the step above it. An upstream step's output is the downstream step's input, so a step that failed on bad data shows its cause one step up. Where a value is built from several references, a [Custom Variables](/build/action-steps/custom-variables) step placed before it echoes the resolved value as its own output. --- ## Live data mapping The Executions tab is not just for debugging. It is the engine that powers the Workflow data panel. When a step runs, Glow keeps what it produced. Open the Workflow data panel in a later step and you pick from those real values, not a bare list of field names. > **Run steps early and often.** Configure your trigger and hit **Run** to > generate a real execution before you go further. As you add the steps after > it, the Workflow data panel shows real values instead of a list of field > names. An actual email subject line, an actual database row. --- ## Handling errors If a step fails, its execution entry is marked in red. Expanding the failed execution reveals the **Error Message** returned by the integration or the Glow engine. It is usually the remote service's own words: ```json { "message": "Request failed with status code 404 (Not Found) - {}" } ``` Compare that against what the step above it produced and the cause is usually obvious: a URL built from an empty variable, a field the API required and did not get. (For a list of common errors, see our [Troubleshooting Guide](/reference/troubleshooting).) ## What's Next? - 👉 **[Activity →](/manage/workspace-settings/activity)**: return to the whole run and workspace alert queue. - **[Error Handling & Retries](/build/core-concepts/error-handling)**: configure what happens after a Step fails. - **[Troubleshooting & Common Errors](/reference/troubleshooting)**: look up the symptom or exact error message.