Skip to content
Rime Documentation

Pipeline Execution

When a pipeline runs, Rime executes its steps according to the DAG dependencies, streaming progress updates to the UI in real time. This page covers how execution works, what you see during a run, and how to investigate issues.

Starting a run

A pipeline run starts in one of two ways:

  • Scheduled — the cron scheduler triggers the pipeline at the configured time. See Pipeline Scheduling.
  • Manual — a user clicks Run Now on the pipeline page.

In both cases, Rime creates a run record, resolves the current pipeline version’s steps and dependencies, and begins executing root steps (steps with no upstream dependencies).

Real-time progress

Pipeline progress is delivered to the browser via WebSocket. You do not need to refresh the page — the DAG view updates live as steps transition between states.

Each step on the canvas shows:

  • Its current state (see below) with a colour indicator
  • Elapsed time since the step started
  • A progress bar for steps that report incremental progress (e.g., extraction row counts)

The pipeline header shows overall status: how many steps have completed, how many are running, and the total elapsed time.

Connecting to progress

When you open a running pipeline’s page, the UI automatically establishes a WebSocket connection and catches up to the current state. If you navigate away and return, you see the latest state immediately — you do not miss updates.

If the WebSocket connection drops (e.g., network interruption), the UI reconnects automatically and reconciles state. A brief banner indicates reconnection in progress.

Step execution states

Each step transitions through the following states:

StateMeaning
PendingThe step is waiting for upstream dependencies to complete.
RunningThe step is actively executing.
SucceededThe step completed without errors.
FailedThe step encountered an error. Retry policy applies if configured.
SkippedThe step was not executed because an upstream dependency failed and the failure policy is set to “continue”. See Building Pipelines.
CancelledThe step was pending or running when the pipeline was cancelled by a user.
RetryingThe step failed and is waiting for the next retry attempt. See retry policies in Pipeline Scheduling.

State transitions follow this flow:

Pending -> Running -> Succeeded
                   -> Failed -> Retrying -> Running (retry loop)
                             -> Failed (retries exhausted)
         -> Skipped (upstream failed)
         -> Cancelled (user cancelled pipeline)

Step-level logs

Each step produces logs during execution. To view them:

  1. Click a step on the DAG canvas during or after execution
  2. The detail panel shows the Logs tab with timestamped log entries

Log content varies by step type:

  • Extract — connection status, tables being synced, row counts per table, upload progress
  • Provision — resource plan (create/modify/destroy), apply progress, resource IDs created
  • Transform — model compilation, execution order, row counts per model, test results
  • Validate — test names, pass/fail status, failure details (expected vs actual)
  • SQL — statement being executed, affected row count, any error messages
  • Webhook — request URL, response status code, response body (truncated if large)

Logs are stored permanently and remain accessible from the execution history.

Error messages

When a step fails, the error message appears prominently at the top of the log panel with a red highlight. Common errors include:

  • Connection timeout — the source system or Snowflake did not respond within the configured timeout
  • Authentication failure — credentials are invalid or expired
  • SQL error — syntax error or invalid reference in a SQL or Transform step
  • HTTP error — webhook endpoint returned an unexpected status code
  • Validation failure — one or more data quality tests failed

The error message includes enough context to begin investigation. For transformation errors, the specific model and SQL statement that failed are identified. For extraction errors, the specific table is identified.

Failure handling

When a step fails (and retries are exhausted), the pipeline’s behaviour depends on the step’s failure policy:

Stop pipeline (default)

All pending steps are marked as skipped. Steps that are already running are allowed to finish (they are not forcibly terminated). Once all running steps complete, the pipeline run is marked as failed.

This is the safest option. It prevents downstream steps from executing with incomplete or incorrect data.

Continue

The failed step is marked as failed. Steps that depend directly on the failed step are marked as skipped. All other branches of the DAG continue executing.

Example:

Extract A (failed) ──> Transform (skipped) ──> Validate (skipped)
Extract B (succeeded) ──> SQL cleanup (runs normally)

Extract A fails. Transform and Validate depend on it, so they are skipped. Extract B and SQL cleanup are on an independent branch and execute normally.

Execution history

Every pipeline run is recorded in the execution history. To view it:

  1. Open the pipeline page
  2. Click the Runs tab
  3. The history shows all runs with:
ColumnDescription
Run IDUnique identifier
VersionThe pipeline version that was active when this run started
TriggerManual or Scheduled
StartedTimestamp
DurationTotal elapsed time
StatusSucceeded, Failed, Cancelled, or Running
StepsSummary (e.g., “5/6 succeeded, 1 failed”)

Filtering history

Use the filters above the history table to narrow results:

  • Status — show only succeeded, failed, cancelled, or running
  • Date range — runs within a specific period
  • Trigger type — manual only or scheduled only
  • Version — runs of a specific pipeline version

Click any run to view the full DAG with step states, logs, and timing for that specific execution.

Cancelling a running pipeline

To cancel a pipeline that is currently executing:

  1. Open the pipeline page while the run is in progress
  2. Click Cancel Run
  3. Confirm the cancellation

Cancellation behaviour:

  • Steps that are pending are immediately marked as cancelled
  • Steps that are running receive a cancellation signal. Each step type handles this differently:
    • Extract steps stop after the current table completes (partial data for the in-progress table is discarded)
    • Transform steps stop after the current model completes
    • SQL steps cannot be interrupted mid-statement — the current statement finishes
    • Webhook steps complete the in-flight HTTP request
    • Provision steps complete the current Terraform operation to avoid leaving resources in an inconsistent state
  • The pipeline run is marked as cancelled once all steps have resolved

Cancellation is not instantaneous. The UI shows a “Cancelling…” state while running steps finish.

Preventing duplicate execution

In multi-replica deployments, Rime uses PostgreSQL advisory locks to ensure that only one instance of a pipeline runs at a time. When a scheduler replica attempts to start a pipeline run, it first acquires an advisory lock keyed on the pipeline ID. If the lock is already held (another replica is running this pipeline), the attempt is skipped.

This means:

  • Scheduled runs are never duplicated, even with multiple scheduler replicas
  • Manual runs while a scheduled run is in progress follow the concurrent execution policy (see Pipeline Scheduling)
  • Advisory locks are automatically released when the run completes or the holding process terminates

You do not need to configure anything for this — it is built into Rime’s scheduler. It is mentioned here because you may see “Skipped (already running)” entries in the execution history, which indicate that a duplicate execution was correctly prevented.

Execution timing

Each run and step records precise timing:

  • Queued at — when the run was created (may differ from start time if queued behind another run)
  • Started at — when execution actually began
  • Completed at — when the last step finished
  • Duration — total wall-clock time from start to completion
  • Step durations — individual timing for each step

Use timing data to identify bottlenecks. If a pipeline takes 45 minutes but 40 of those minutes are a single Transform step, optimising that transformation (or running models incrementally) will have the most impact.

Next steps