> For the complete documentation index, see [llms.txt](https://flapjax.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://flapjax.gitbook.io/docs/automations/monitoring-runs-and-participants.md). # Monitoring Runs & Participants Every automation carries a monitoring page. It answers three questions: is this running, for whom, and where does it go wrong? Sequences show it as **Participants**, which is person-centric. Workflows show it as **Runs**, which is execution-centric. Same page, same tools, different lens. ### Getting there * From the automation's detail page, through the **Runs** or **Participants** control. * From the automations list, through the row menu and **View runs**. * From [Settings โ†’ Failed Actions](/docs/troubleshooting/failed-actions.md), where **View automation run** on a failure opens that exact run, filtered to failures and focused on the failed step. Viewing needs the automations view permission. The page is **read-only**. You cannot cancel, retry or re-enrol from here. Retries happen automatically in the platform, and this page shows them. ### Page layout A split view. * **Left** holds the runs or participants table, under an **Overview** statistics header. * **Right** holds the automation's **flow diagram in analytics mode**. With nothing selected it shows aggregate numbers per action. Select a run and it lights up with that run's step-by-step outcome. * Drag the divider to resize. The automation name at the top renames inline. The page does not update live. Press **Refresh** for the latest runs. ### Overview statistics Cards above the table: * **Completed**, runs that finished successfully. Click to filter the table to them. * **Failed**, runs that hit an error. Click to filter to failures. * **Participants**, on sequences alone, counting the distinct people who entered. * **Total runs**. * **Success rate**, a coloured ring: green at 95% and above, amber at 70% and above, red below that. ### Filtering * **Status chips** toggle **Successful** and **Failed**. At least one stays on. Arriving from a failure deep-link pre-selects Failed. * **Date range** takes presets or a custom from-and-to, applied to when runs happened. * **Person search**, on sequences alone, finds a participant by name as you type. * Active filters appear as removable chips, with **Clear all**. The list loads 50 at a time as you scroll, newest first. A toggle flips the order. *** ## Workflows: the Runs table One row is **one run**, a single execution of the workflow, identified by a run ID. | Column | Shows | | ----------- | --------------------------------------------------------------- | | **Run** | A coloured status bar, the run's short ID, and a copy-ID button | | **Run At** | The time the run started | | **Status** | A status pill, covered below | | **Failure** | On failed runs, a preview of the error. Hover for the full text | **Status pills:** | Pill | Meaning | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | ๐ŸŸข **Success** | Every step completed | | ๐Ÿ”ด **Failed** | A step errored. Click the pill for the error details popover. A run counts as failed once any step fails, even where later steps succeeded | | ๐ŸŸก **Partial Error** | The run finished, and a step reported a partial problem | | ๐Ÿ”ต **Retrying** | The platform is re-attempting the run | | **Retry #n** badge | This run is the n-th automatic retry of an earlier failed run | ## Sequences: the Participants table One row is **one person** who entered the sequence, whatever number of times they ran through it. | Column | Shows | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | The person, with a **View Profile** link to their page | | **Recent runs** | Up to eight coloured bars, green for successful and red for failed, newest first. Hover for the "X successful ยท Y failed ยท Z total" tally, with a **+N** for older runs | | **External ID** | Their identifier in your systems | | **Last activity** | The time the sequence last did something for them | Click a person to inspect their runs. Anyone who went through more than once gets a **run-date dropdown** in the context bar, which switches between their entries. *** ## Inspecting a run Click a run, or a participant, and the right-hand flow diagram becomes that run's story. Each action node shows how that step fared for this execution. A floating **context bar** appears with: * The run's overall status, the person's name on sequences, and the run's **total duration**. * **Previous** and **next run** arrows. The keyboard works too: `j` and `k` step through runs, `Esc` deselects. * A **retry chain** on any retried run. Pills show the lineage of Original, Retry #1, Retry #2 and so on. Click a pill to jump to that attempt. * An overflow menu holding **Copy run JSON** for the full step data, **Export run as CSV** with one row per step covering action, status, time, duration and error, and **Copy permalink**, a URL that reopens this exact run. Paste it into a ticket or a chat. ### The timeline panel The timeline button opens a chronological list of the run's steps. Each step shows: * A status dot in green, red or amber, plus the action's icon and name. * Its **duration** and the exact time it executed. * The error message inline, on failed steps. * **Wait markers** between steps, reading *+5m*, *+2h* or *+3d*, wherever the run paused for a delay or a wait-for-event. You see at a glance where time went and where work happened. Arriving from Failed Actions lands you here, with the failed step already focused. ### Aggregate mode, with nothing selected With no run selected, the flow diagram shows **per-action totals** across every run in your current filter: executions, success rate, average duration, and the spread of runs across the paths after a branching step. This is the fastest way to spot which step fails most, or which branch swallows everyone, before you drill into individual runs. *** ## Practical flow: debugging a failure 1. Open the page, or arrive from [Failed Actions](/docs/troubleshooting/failed-actions.md) already focused. 2. Filter to **Failed** and set the date range around the incident. 3. Check aggregate mode. Is one action node carrying all the failures? 4. Click a failed run, read the step's error in the timeline, then check the wait markers and durations for surprises. 5. Fix the automation, whether the configuration, the [fallbacks](/docs/automations/actions.md#variable-colours-reading-a-chip-at-a-glance) or the data. Then watch new runs come through green. On an auto-retried run, the retry chain shows whether the retry recovered it. Flapjax keeps run history for roughly 13 months by default, then ages it out.