> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Play runs > Executions of Plays, with saved identities, progress, results and controls. A **Play run** is one execution of a Play with a specific input and code snapshot. Its run ID connects progress, results, datasets, logs and usage. You can inspect that same run from the web app, CLI or SDK, regardless of how it started. For example, one run can enrich a pilot CSV and another can process the full file. They use the same Play but have separate identities and outcomes. A webhook or scheduled occurrence also starts its own run. ## From launch to completion Starting a Play returns a public run ID before the workflow necessarily finishes. The run retains its admitted code snapshot. Later edits or publication do not change that execution. The primary run lifecycle distinguishes active work from terminal outcomes: | Status | What it means for the caller | | - | - | | `queued` | Work is accepted and awaits execution. | | `running` | The workflow is executing. | | `waiting` | The workflow is waiting for a supported continuation, such as an event or delay. | | `completed` | The handler finished and its result can be inspected. | | `failed` | Execution ended with a failure. | | `cancelled` | Execution ended through cancellation. | Waiting can be part of the design, such as a human approval. An error, a stalled operation and a deliberate wait need different responses. Status, recent activity and failure details help distinguish them. A caller can wait synchronously or return while the run continues. Closing an agent chat or reaching a local polling timeout does not cancel the remote run. ## Progress, graphs and row results The Play graph shows the workflow's steps and decisions. Run progress connects that graph to observed execution. A failed step helps locate a problem without requiring the entire workflow to be repeated. For row-oriented work, datasets connect input records, computed columns and row outcomes. A batch can contain successful rows, legitimate no-match results and failed rows under its configured failure policy. The run's overall status does not replace inspection of those row outcomes. Run summaries stay compact. They provide counts, progress, dataset references and previews rather than every retained row. The web app can display dataset rows, and export retrieves a selected run's retained data without starting new provider work. An export from an active run can be partial. A scalar result can require a full-result read. A dataset instead has its own row retrieval and export path. The returned dataset paths and export actions identify the relevant output, including datasets nested in the result. ## Result visualizations The web app presents result tables, dataset cells, the execution graph and run activity. These views connect an output to the input and steps that produced it. For a chart of arbitrary result columns, an agent can export the saved rows and create a chart or report from that output. This reads existing work without executing the Play again. For example, a qualification run can support an accounts-by-segment chart and a summary of unresolved records. The chart needs the selected run and dataset, the complete exported population, and explicit filters. A preview contains only a sample. [Visualize a saved result](https://deepline.com/docs/sdk-v2/visualize-data.md) explains this workflow and how to keep the chart's counts traceable to its source. ## Logs, events and failure details Logs contain messages recorded during execution. Structured logs can include the authored step, severity and custom context. Events describe lifecycle and work outcomes, such as a run starting, a step failing or a saved result becoming available. The CLI and SDK support filtered reads, retained counts and summaries. These help answer questions such as which step failed or how many matching events occurred in a chosen window. Retention limits still apply. Some saved operation results are available through event payload retrieval. Those results can explain a provider response or failed call. They do not replace dataset export. [Run logs and events](https://deepline.com/docs/sdk-v2/run-events.md) documents the query and retrieval contracts. A completed run can contain failed rows or no usable match. A failed run can still have useful retained results. Acceptance rules determine which business outputs can proceed. ## Recovery and reruns **Recovering observation** means reading the existing run again. A saved run ID lets a restarted application or agent inspect its status and retrieve its results. It does not submit another execution. **Rerunning** starts a new run. Where retained input and artifacts are available, the rerun path can use the original snapshot and supported input changes. The new run has its own identity and can perform new provider work. Durable execution can reuse completed work during recovery. Reuse across new work depends on freshness and the operation's contract. An old run ID or a stable step name alone does not make a new run free or its external effects exactly once. If the initial submission response is lost before the run ID is saved, the caller must reconcile the uncertain launch before submitting again. The [application integration guide](https://deepline.com/docs/sdk-v2/production-integration.md) covers launch intent, saved IDs and idempotent destination writes. ## Cancellation and independent children An explicit stop request cancels a run when its business result is no longer needed. The server can confirm a stop immediately or accept cancellation while cleanup continues. An accepted `cancelling` response requires observing the same run until it reaches a terminal state. Stopping a run does not undo an external write that already happened. It also does not disable its schedule, webhook or upstream Monitor. Future work needs the corresponding [trigger](https://deepline.com/docs/play-triggers.md) or [Monitor](https://deepline.com/docs/plays/monitors.md) control. Inline child Plays share the parent's execution. Independently launched `deepline.runPlayAsync` children have their own IDs and lifecycle. Already admitted children continue after parent completion or cancellation unless separately stopped. Their lineage helps callers inspect the related runs. ## Usage and notifications Usage answers what the run consumed, separately from whether its business result was useful. Empty results, failed work and pending settlement do not establish zero usage. [Cost control](https://deepline.com/docs/cost-control.md) explains per-run usage and workspace spending limits. Notification settings determine which supported Play outcomes reach a recipient. Rules can select all runs, scheduled runs, webhook-triggered runs or a specific Play. A failure rule can match each failure or a configured number of consecutive failures. Delivery timing, destinations and recipient preferences control notification delivery. A failed run does not promise email to every member, and failed dataset rows need their own inspection. See [Workspace notifications](https://deepline.com/docs/workspaces.md#notifications) for settings, supported destinations and delivery checks. ## Continue learning * [Run Plays and view results](https://deepline.com/docs/sdk-v2/calling-plays.md): start, inspect and export a run. * [Run logs and events](https://deepline.com/docs/sdk-v2/run-events.md): investigate retained activity. * [Integrate a Play into your app](https://deepline.com/docs/sdk-v2/production-integration.md): recover caller state and apply results. * [Runtime API reference](https://deepline.com/docs/sdk-v2/api-reference.md): exact status, output and stop contracts. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.