# Monitor and control job runs

> Source: https://docs.clonepartner.com/ui/job-runs/

A job run is one execution of a job's task graph. Its detail page combines overall status, selected task scope, dependency order, individual task status, timing, and links to the underlying task runs.

## Status model

A job run may be pending, running, paused, completed, failed, or cancelled. Each task row has its own pending, running, terminal, or skipped state and links to the underlying task run after one is created.

The overall job status summarizes the graph; it does not replace checking individual failures and skipped dependencies.

## Read the task graph

The task list shows:

- job task key and task name;
- dependency order;
- current or terminal status;
- elapsed time;
- underlying task run.

A downstream task may not start when a required dependency fails. That is distinct from the downstream task itself failing.

## Live updates and task details

While a run is active, the page subscribes to job and task status events. If the live connection is interrupted, reload to reconcile with stored run state.

Open an underlying task run for its metrics, step counts, and logs. Those persisted task-run details are the source for post-run review.

Logs can contain record identifiers and provider error text. Access them only from an authorized session and avoid copying sensitive payloads into tickets.

## Stop a run

Use **Stop** when continuing would be unsafe or wasteful. Stopping:

- requests cancellation of active task processes;
- prevents pending graph work from starting where possible;
- does not roll back completed external writes.

After stopping, reconcile destination state before starting another run.

## Resume a failed or paused run

**Resume** is available for `failed` or `paused` runs and starts the remaining work according to the stored job-run snapshot. Completed tasks are not automatically treated as reversible.

Before resuming:

1. identify the first failed task and its error;
2. correct the external or configuration problem;
3. determine whether the failed operation may already have succeeded;
4. verify completed task outputs are still valid;
5. confirm writes are idempotent;
6. resume and watch the new task attempt.

Create a new run instead when the job configuration, connector binding, task definition, or intended scope must change.

## Investigate a failure

1. Read the first causal error, not only downstream skips.
2. Open the linked task run.
3. Compare processed, output, skipped, and error counts.
4. Review a narrow log interval around the failure.
5. Verify connector health and provider limits.
6. Inspect the run's configuration snapshot.
7. Reconcile ambiguous external writes.

For central log storage and reconnection behavior, see [VictoriaLogs](/operations/victoria-logs) and [Live run monitoring](/operations/live-run-monitoring).