Skip to main content

Runtime Executions

App page

Runtime Executions is the audit trail. Every workflow run (scheduled or manual) writes a record here.

What you can do​

  • View all runs for your account.
  • Filter by date range and status.
  • Open a run to see:
    • Run log (collapsible).
    • Per-node metrics (collapsible).
    • Per-node details and payload samples (when enabled on the node).
  • Project names in the list are hyperlinks to open the project that produced the run.

Deep-link directly to a specific run detail using query parameters:

/runtime-executions?projectId=<projectId>&runId=<runId>

A few places in the UI use this:

  • The project detail header "Last execution" badge links to the last run for quick investigation.
  • The Dashboard's Needs Attention lane links to failed scheduled-job executions.

Reading a run​

  • Status is running, succeeded, failed, or cancelled.
  • Duration is wall-clock from start to terminal state.
  • Per-node row counts show how many rows entered and exited each node.
  • Payload sample shows the actual rows that flowed through the node (subject to the node's sample-payload setting).
  • Logs are timestamped lines emitted by the runtime, indented by node.

Don't see a run?​

  • The run was a Quick Debug Run on the canvas; those don't write Runtime Execution records.
  • The schedule hasn't fired yet -- check the Jobs page for the next run time.
  • The runtime is offline -- check Environments > the env > Runtime Agents for agent health.

Auto-clean​

Runtime file staging under stage/<runId>/... is automatically purged after a run completes (success or failure) to prevent disk buildup. Log entries and execution records are retained per the platform retention policy.