# Job runs > Source: https://docs.clonepartner.com/using/job-runs/ # Job runs A Job Run is one execution of a Job's task DAG. Its detail page (reached from a Job's **Recent Runs** table, or automatically after you start a run) shows overall status, per-task progress, and live updates while work is in flight. ## Screen overview The header reads **Job Run #<id>** with a status badge. Below it, a metadata grid shows **Started**, **Duration** (ticking live while the run is active), and — when the run failed — an **Error** message. The main table lists every task in the run's scope, in dependency order: | Column | Contents | |---|---| | **Task** | The DAG node key | | **Type** | `command` or `validation` badge, or "migration" for regular tasks | | **Status** | The task's current or terminal status badge | | **Started** | The task's start time, or a dash if it has not started | Tasks that have not started yet appear as `pending` rows, so you can see the full planned scope up front. When the run was started with selected tasks only, the table shows just those tasks (plus their dependencies, unless dependencies were skipped). Under a `command` or `validation` task's row, the task's result messages appear inline with info, warning, or error styling — validation output is readable without leaving the page. While the run is active, the page subscribes to job and task status events and updates in place. If the connection drops, reload the page to reconcile with stored state. ## To drill into a task run Task rows that have an underlying Run are clickable and open that Run's detail page, with its metrics, arguments, and logs. See [Tasks and task runs](/using/tasks-and-runs/). Rows without a Run yet (pending or skipped tasks) are not clickable. ## To stop a job run 1. Open the Job Run page while its status is `running`. 2. Select **Stop** (admin or superadmin role required). 3. The run moves to a terminal state. Stopping does not roll back writes that tasks already completed against external systems — reconcile destination state before starting another run. The button calls `POST /api/jobs/:id/stop` and appears only while the run is `running`. ## To resume a job run 1. Open a Job Run whose status is `paused` or `failed` — the only states in which **Resume** appears (the server rejects a resume for any other status). 2. Fix whatever caused the failure first: correct the external condition, Connector credentials, or configuration. 3. Select **Resume** (admin or superadmin role required). The remaining work restarts and the page resumes live updates. Resume continues from where the run stopped; completed tasks are not re-executed. If the Job's configuration, connector bindings, or task definitions must change, start a new run from the Job page instead. ## Failure policies What happens to the rest of the DAG when a task fails is set by the template's `on_failure` policy: - `pause` (the default) — the run stops in a resumable `paused` state. Fix the cause, then **Resume**. - `abort` — the run fails immediately. - `continue` — tasks that do not depend on the failed task keep running. A `validation` task whose result reports `fail` stops the job even though its process exited normally — check the inline result messages, not only exit status. See [Run lifecycle](/concepts/run-lifecycle/) for the full state model. :::callout{type="tip"} When investigating a failure, find the first causal error rather than downstream tasks that were skipped because a dependency failed. Open the failed task's Run for its logs and error details. ::: ## Related - [Jobs and job templates](/using/jobs/) — where Job Runs are started and listed - [Tasks and task runs](/using/tasks-and-runs/) — the per-task Run pages behind each row - [Run lifecycle](/concepts/run-lifecycle/) — statuses and failure policies in depth - [Live run monitoring](/operations/live-run-monitoring/) — how live status and log streaming work