Skip to main content
If a task is the durable definition of work to perform, an execution is the runtime record of what happened when the platform attempted that work—whether the task was a classic URL list, a modular action, or a multi-step plan.

​
What an execution represents

An execution captures:
  • When the task was run
  • The current lifecycle state
  • Which output was produced
  • Whether the work completed, failed, or was stopped
Executions are the main object users monitor after triggering work.

​
Typical execution flow

At a high level, an execution moves through a platform workflow like this:
  1. The execution is created
  2. Work is queued or assigned
  3. A worker performs the assigned work
  4. Data and media are returned through ingestion
  5. Results become available through user-facing APIs
The exact runtime details depend on the worker type, but the user-facing model remains the same.

​
Why executions are separate from tasks

Separating tasks from executions gives the platform a clean operating model:
  • Users define tasks once
  • The same task can run many times
  • Each run keeps its own status and outputs
This is especially important for scheduled tasks, where one definition may produce a long history of executions and datasets.

​
Monitoring executions

The main user actions around executions are:
  • List executions
  • Inspect one execution
  • Pause, resume, or stop work when supported
  • Retrieve results when the execution completes
Task Service is the primary API for these workflows.

​
Execution outputs

Completed executions can expose:
  • Structured result data
  • Exported CSV or JSON
  • Datasets derived from completed output
  • Stable platform URLs for media assets
This keeps execution monitoring and execution result access tied together in the same public surface.

​
Next steps