Runs

A run is a single execution of a schedule. Runs are created automatically when a schedule fires on its cron expression, or manually when someone clicks Run Now or triggers one via the REST API. Every run is recorded — its status, timing, log output, and any files it produced — so you can inspect what happened and when.

Run statuses

Each run moves through a lifecycle represented by one of seven statuses.

Status	Meaning
pending	Queued; waiting for an available executor to pick it up
running	An executor has picked it up and the workflow or script is executing
canceling	An abort was requested; the executor is stopping the process
passed	The execution completed successfully
failed	The execution completed with an error or non-zero exit code
canceled	The run was aborted before it could complete
skipped	The schedule was triggered while a run of it was already active and its Concurrency setting is Skip

The statuses pending, running, and canceling are active states — the run detail page polls automatically and updates in real time while a run is in any of these states. A skipped run never executes — it is recorded directly in its terminal state so you always know the trigger happened. See Concurrency for how the Skip, Queue, and Cancel & Replace strategies affect run creation.

Your runs

The run list shows all runs in the current project, most recent first. Each row shows the run status, the description and any executor tags, the schedule and environment it belongs to (with a warning icon if either has been updated since the run was created), and when the run was created and by whom.

You can filter by status and search by description. The list loads 25 runs at a time and extends automatically as you scroll.

Each run has three actions in the list:

• Abort — cancel an active run. See Aborting a run.
• Retry — create a new run from the same schedule. See Retrying a run.
• Delete — remove a completed run. See Deleting a run.

Run detail

Click any run to open its detail page. The page shows a set of summary cards followed by the log output.

Triggered by — whether the run was started automatically by its cron schedule or manually (via Run Now or the API), the user whose action created it, and when.

Executor — the executor that ran this run, including its tags. If no executor has been assigned yet (a pending run), this shows "No executor assigned yet".

Environment — the environment used for this run, with a link to the environment page. A warning icon appears if the environment has been modified since the run was created — relevant if you plan to retry.

Schedule — the schedule this run belongs to, with a link to the schedule. A warning icon appears if the schedule has been modified since the run was created.

Tags — the executor tags that were applied to this run, controlling which executor could pick it up.

Duration — how long the run spent queued and how long it spent executing. While a run is active, the elapsed time updates live. If Runner has historical data for this schedule, a progress bar shows how far through the expected duration the run is. The bar turns red if the run exceeds the estimated duration.

Status and artifact — the current run status. If the run produced files in the /nodepit directory, a download link for the artifact archive appears here.

Resource metrics

While a run is executing and for any completed run that collected metrics, Runner displays six time-series graphs:

• CPU — CPU usage as a percentage of the allocated limit
• Memory — memory usage in bytes
• Network Received / Network Sent — cumulative bytes received and sent over the network
• Disk Read / Disk Write — cumulative bytes read from and written to disk

These metrics are collected from the executor's Docker container. They are useful for spotting resource bottlenecks, such as a workflow that runs out of memory or a script that reads an unexpectedly large dataset.

Log

Below the summary cards, the log viewer shows the complete output of the run. Lines are colored by log level — errors in red, warnings in orange, debug output in gray, and all other output in the default color.

The log viewer toolbar provides several controls:

• Search — opens an inline search bar. Options: Aa to match case, W to match whole words only, and .* to use a regular expression. Use the up and down arrows or Enter / Shift+Enter to jump between matches.
• Scroll to top / Scroll to bottom — jump to the first or last line.
• Follow Log — automatically scrolls to the bottom as new lines arrive. Only available while the run is active; turns off when the run completes.
• Copy Log — copies the full log text to the clipboard.
• Download Log — downloads the log as a file.

You can also click any line number to anchor a link to that line — the URL updates so you can share a direct link to a specific point in the log. Shift+click extends the selection to a range; Cmd+click (or Ctrl+click) toggles individual lines in and out of the selection.

Aborting a run

Aborting a run sends a cancellation signal to the executor and moves the run to canceling, then canceled once the process has stopped. Only runs in pending or running state can be aborted.

Owners and Maintainers can abort any run in the project. Operators can only abort runs they triggered themselves.

Retrying a run

Retrying creates a new run using the same schedule and environment. The new run is added to the top of the run list and goes through the normal lifecycle.

If the schedule or environment has been updated since the original run was created, Runner shows a confirmation dialog explaining the difference — the retry will use the current versions of both, which may produce different results.

Retrying requires at least the Operator role and a valid Runner license. The Retry button is disabled if no valid license is installed.

Deleting a run

A run can only be deleted once it has reached a terminal status — passed, failed, or canceled. Active runs must be aborted first.

Owners and Maintainers can delete any run in the project. Operators can only delete runs they triggered themselves.