Canonical page: https://docs.teloring.com/docs/product/studio/executions Last modified: 2026-09-02T07:03:21.000Z # Executions — see what your flow did An **execution** is one run of a flow, recorded from the moment its trigger fired to the moment the last path ended. **Executions** is where you read those runs back: what set each one off, what every block was handed, what it returned, which branch it took, and where it stopped. This is the page to open when someone says *"the bot replied the wrong thing"* or *"the flow didn't do anything"*. Instead of guessing from the customer's side, you see the run itself.  :::note Executions are **per flow**. Open the flow you want to investigate, then open Executions from its top bar. There is no account-wide run list. ::: ## Opening Executions 1. Open **Studio** from the left sidebar. 2. Click the flow you want to investigate. 3. Click **Executions** in the editor's top bar. The page opens over the canvas. Your canvas is untouched underneath — **Back to the canvas** (the arrow at the top left) returns you to exactly what you were editing, unsaved changes included. ## What gets recorded | Recorded | Not recorded | | --- | --- | | Real runs — a customer messaged you, a form was submitted, a schedule came due, a webhook fired | [Simulator](./simulator.md) sessions. A dry run is not a run, and never appears here | | [Test Run](./publishing.md#test-run) results, marked **Test runs** so you can filter them out | Anything that happened before this feature was released | | Every block that executed, in order, with its inputs, outputs, errors and timing | Blocks that never ran — they are shown dimmed on the replay instead | Recording starts the first time a flow runs after the feature is released. A flow that has been live for months starts with an empty list and fills up from its next run. ## The list ### Header | Element | What it is | | --- | --- | | **Executions** | The page title, with a one-line description of what you are looking at. | | **Retention pill** | How many runs are kept right now, out of how many your plan allows, and the plan's name. Hover it for the full rule. See [How much history you keep](#how-much-history-you-keep). | | **Refresh** | Reloads the rows and the counts. Runs do not stream in live — refresh after you have tested something. | | **←** (top left) | **Back to the canvas.** | ### Status tiles Four tiles sit under the header. Each one is also a shortcut: click it and the **Status** filter jumps to that value. | Tile | Counts | Clicking it | | --- | --- | --- | | **Runs kept** | Every run currently stored for this flow | Clears the status filter | | **Completed** | Runs where every path finished | Filters to **Completed** | | **Failed** | Runs where a block returned an error | Filters to **Failed** | | **Waiting** | Runs paused right now, waiting for a customer reply or a timer | Filters to **Waiting** | **Failed** is the tile to watch. A number that climbs after a publish usually means the change broke something. ### Filters | Filter | Options | What it does | | --- | --- | --- | | **Status** | Any status, Completed, Failed, Waiting, Running, Timed out, Cancelled | Shows only runs that ended that way. See [Run statuses](#run-statuses). | | **Run type** | All runs, Real runs, Test runs | Separates real customer traffic from your own **Test Run** results. | | **From** | A date and time | Only runs that started at or after this moment. | | **To** | A date and time | Only runs that started at or before this moment. | | **Sort by** | Newest first, Oldest first, Slowest first, Fastest first | The order of the rows. | | **Clear filters** | — | Resets everything back to *all runs, newest first*. | Filters apply as soon as you change them. :::note Picking a **From** or **To** date forces the order back to **Newest first** or **Oldest first** — a date range and a duration sort cannot both decide the order. The **Sort by** dropdown updates itself so it always shows the order the rows are actually in. ::: ### A row Each row is one run. | Element | What it tells you | | --- | --- | | **Coloured dot** | The outcome at a glance — teal completed, red failed, amber waiting, coral running, grey cancelled. Waiting and running pulse. | | **`#42`** | The run's number. Runs are numbered per flow, so `#42` in one flow is unrelated to `#42` in another. | | **Status chip** | Completed, Failed, Waiting, Running, Timed out, Cancelled. | | **Test chip** | Present only on a **Test Run**. Real customer runs have no chip. | | **`v3`** | Which published version of the flow ran. Useful when a run predates your last publish. | | **Quoted text** | The customer message that set the run off. When there is no message — a schedule, a webhook — the trigger's name is shown instead. | | **Red line** | The run's error, when it has one. | | **Date and time** | When the run started, in your own timezone. | | **Duration** | How long the whole run took, from trigger to last path. | | **`n steps`** | How many blocks executed. | | **`n failed`** | How many of those failed. Only shown when it is not zero. | Click anywhere on a row to open the run. **Load more** at the bottom fetches the next 25 rows. It appears only when there are more. ## Replaying a run Clicking a row loads that run onto the canvas and plays it back.  A light travels the path the run actually took: each block lights up in turn, and a glowing pulse runs along each connection in the order it was crossed. It is the fastest way to see the shape of what happened — where the flow branched, and where it stopped. :::caution A replay is a recording, not your flow Nothing on this canvas can be moved, edited, connected or deleted, and **Publish** is switched off. You are looking at a record of something that already happened. **Exit preview** returns you to your draft, exactly as you left it. ::: ### The replay banner | Control | What it does | | --- | --- | | **Run #42 · Completed** | The run and its outcome, with the coloured dot beside it. | | Second line | When it started, how long it took, the flow version, and a **Test runs** marker when it was one. | | **▶ Replay** | Plays the travelling light again from the beginning. | | **Back to executions** | Returns to the list, keeping your filters. | | **Exit preview** | Closes the replay and restores your draft. | ### What the canvas shows | What you see | What it means | | --- | --- | | **Teal ring** around a block | It ran and completed. | | **Red ring** | It ran and failed. | | **Amber ring** | The run paused here — waiting for a customer reply or a timer. | | **Dimmed block** | It never ran in this execution. | | **Numbered badge** | The step order — `1` is the trigger, `2` is the next block that ran, and so on. A block the flow entered twice shows the number of its last visit. | | **Bright teal connection** | The run crossed this connection. | | **Faded connection** | This path was not taken. | Click any block on the canvas to jump to its step in the panel on the right. ### The flow this replay draws Studio stores a snapshot of the flow's layout each time you publish a new version, and a replay is drawn against the snapshot the run actually used. **Blocks you have deleted since still appear**, wired the way they were, so an old run makes sense even after you have rebuilt the flow. If no snapshot exists for a run — for example a run recorded before its version was snapshotted — the canvas falls back to the flow as it stands today and says so, both in the banner and above the steps: > No snapshot was stored for this run, so the canvas shows the flow as it stands today. Blocks may have changed since. ## The Steps panel The right-hand panel becomes the run's timeline.  ### Run summary | Field | Meaning | | --- | --- | | **Outcome** | Completed, Failed, Waiting, Running, Timed out, or Cancelled. | | **Started** | When the trigger fired. | | **Took** | Total duration. | | **Trigger** | Which trigger block started the run. | | **Flow version** | The published version that ran. | | **Conversation** | The conversation the run belonged to, when it had one. | | **Waiting for** | Only on a waiting run — *a reply from the customer*, *a reply that matches a branch*, or *a Wait block's delay*. | A red box below the summary carries the run's error, when there is one. ### The step list Every block that executed, in order. Each entry shows its step number, the block's name, its type, how long it took, and its error if it had one. | Colour | Meaning | | --- | --- | | Teal number | The step completed. | | Red number | The step failed. | | Amber number | The run paused at this step. | A block that has since been deleted from the flow is tagged **block since deleted**. Its step stays on the timeline — what happened, happened. :::note A block can appear twice The list is a record of *what ran*, not of *which blocks exist*. A condition the flow legitimately re-enters — because the first customer reply matched nothing and a second one arrived — appears twice, in the order it ran. That is usually the answer to "why did the customer get asked the same thing again?". ::: ### One step in detail Click a step (or click its block on the canvas) to open it. | Section | What it holds | | --- | --- | | **Ran at / Took** | When this single block executed, and how long it took. | | **Error** | The block's error message, when it failed. | | **Branch taken** | For conditions — which output port the run left through. | | **Handed to this block** | The block's settings *as the block received them*, with every `{{variable}}` filled in. | | **Returned by this block** | The [output variables](./variables.md) the block produced, which everything downstream could then use. | **Handed to this block** is the section that answers most questions. A field you wrote with variables shows both halves: ```text message_text Hi Dana, your order is ready ⟵ Hi {{contact.contact_name}}, your order is {{var.status}} ``` The value on the left is what the block actually used. The template on the right is what you wrote. When a message comes out wrong, this tells you immediately whether the wording was wrong or a variable was empty. :::note Credentials are never shown here Settings whose name looks like a secret — `Authorization`, `api_key`, `token`, `password` and similar — are replaced with `••• redacted •••`. You can still see them in the block's own settings on the canvas; they are kept out of the run log because run logs get exported, screenshotted and pasted into support tickets. ::: ## Run statuses | Status | Meaning | What to do | | --- | --- | --- | | **Completed** | Every path finished. | Nothing — though "completed" only means no block errored. Read the steps to check it did the *right* thing. | | **Failed** | A block returned an error. Other branches kept running. | Open the run and find the red step. | | **Waiting** | The run is paused, waiting for a customer reply or a Wait countdown. | Normal for a chatbot. It becomes Completed when the customer answers, or Timed out if they never do. | | **Running** | Executing right now. | Refresh in a moment. Most runs finish in under a second. | | **Timed out** | A wait expired before the customer replied. | Consider a shorter timeout, or a branch that handles silence. | | **Cancelled** | The run was stopped — usually because the flow was paused or deleted while it was mid-conversation. | Expected after a pause or a delete. | ## How much history you keep Your **subscription plan** decides how many finished runs each flow keeps. The retention pill in the header always shows where you stand: > **412** of 500 kept · **Free** The rule is **oldest out, newest always kept**. On a plan that keeps 500, run 501 is recorded in full and the oldest finished run is removed to make room — so you always hold the most recent 500. You never lose a new run because the flow is at its limit. | Point | Detail | | --- | --- | | Counted per flow | A busy flow cannot push a quiet flow's history out. Each flow keeps its own last N. | | Never removed | A run that is still **Running** or **Waiting** is live state — a customer sitting mid-conversation with your bot — so it is never deleted to make room, whatever its age. | | Deleting the flow | Takes every run with it. There is no history after a flow is deleted, and no way to get it back. | | Changing plan | Moving to a smaller plan trims each flow down to the new number over its next few runs. Moving up simply lets history grow further. | | Nothing is blocked | Retention is a depth, not a quota. Hitting it never stops a flow from running, and never stops you from changing plan. | The exact number per plan is shown on **Billing → Plans**, on every plan card, alongside agents, storage and analytics history. :::tip Save a run before it ages out Retention has no "pin this run" button. If a run matters — a bug you are reporting, a case you want to review next week — take a screenshot of the steps panel while it is open. ::: ## Test runs and real runs **[Test Run](./publishing.md#test-run)** results are recorded here too, tagged **Test runs**, and they count towards your retention. Use **Run type → Real runs** while investigating a customer complaint, so your own testing does not clutter the list. :::tip Testing a chatbot? Use the simulator instead [Test Run](./publishing.md#test-run) fires the flow once with sample data and records an execution. The **[Simulator](./simulator.md)** lets you hold a whole back-and-forth conversation with your bot, records nothing, and sends nothing. For chatbots it is almost always the better tool. ::: ## Permissions | To do this | You need | | --- | --- | | Open Executions, read runs, replay them | **Studio → Read** | | See the customer's own messages inside a run | **Customers → Conversations → Read** as well | Studio permission is not conversation permission. Without **Customers → Conversations → Read**, the run's structure is still fully visible — which branch it took, what failed, how long it took, what your flow sent — but the customer's own messages and contact details are hidden, with a note saying why: > The customer's own messages are hidden because your role does not include reading conversations. The flow's own logic — which branch it took, what failed, how long it took — is all shown. Every default role that grants Studio also grants Conversations, so most accounts never see this. It matters only for a custom role built with one and not the other. See [System permissions](../roles/system-permissions.md). Nobody can edit or delete a run — there is no permission that allows it. Runs leave only through retention or by deleting the flow. ## Limits | Limit | Value | | --- | --- | | Runs kept per flow | Set by your plan. See [How much history you keep](#how-much-history-you-keep). | | Rows per page | 25, with **Load more** | | Steps recorded per run | 400. A run that somehow does more keeps the first 400 — where a runaway flow goes wrong is at the start. | | Long values in a step | Truncated, with the number of characters dropped shown at the cut. | ## What Executions cannot tell you | Question | Where to look instead | | --- | --- | | Why didn't the flow start at all? | No run means no trigger matched. See [Troubleshooting → The flow never runs](./troubleshooting.md#the-flow-never-runs). | | What did the customer see on their phone? | The conversation itself, in the inbox. | | Who published this version? | [Version history](./publishing.md#version-history) and the **Audit Log** in Settings. | | How is this flow doing overall, this month? | [Analytics](../analytics.md). Executions is per-run, not a report. | ## Next - [Test your chatbot with the simulator](./simulator.md) — hold a conversation with your bot before it meets a customer. - [Testing & publishing](./publishing.md) — draft versus live, version history, rolling back. - [Troubleshooting](./troubleshooting.md) — when a flow does not fire at all.