GitHub
Concept

Execution & Monitoring

Live streaming, execution history, approvals, retries, artifacts, and cost tracking for workflow runs.

Execution & Monitoring

Once a workflow is triggered, ProxifAI provides full visibility into every execution — live streaming, detailed logs, approval flows, and cost tracking.

This page covers what happens during a run. For where the run happens — fresh container per execution vs. a warm pool — see Execution modes.

Live Streaming

Watch workflow steps execute in real-time:

  • Step-by-step progress — the workflow graph highlights the currently executing step
  • Terminal output — stream agent and command output as it happens via WebSocket
  • Status indicators — each step shows pending, running, succeeded, failed, or waiting-for-approval
  • Auto-scroll — output follows the latest log lines; scroll up to pause and review earlier output

Live streaming is available from the workflow run detail page. Multiple team members can watch the same execution simultaneously.

Execution History

Browse all past workflow runs from the Executions tab:

ColumnDescription
Run IDUnique identifier for the execution
TriggerWhat started the run (event, schedule, webhook, manual)
StatusSucceeded, failed, cancelled, or running
DurationTotal wall-clock time from start to finish
CostCredits consumed by the execution
Started byUser or system that initiated the run
TimestampWhen the execution started

Filter history by status, trigger type, date range, or initiating user. Click any row to view the full execution detail.

Human-in-the-Loop Approvals

Workflows can pause at designated steps and wait for manual approval before continuing:

  • Approval steps — insert approval gates between critical workflow stages (e.g., before deploying to production)
  • Inbox integration — approval requests appear in the approver’s ProxifAI inbox with context about the workflow and its outputs so far
  • Slack notifications — if Slack is connected, approval requests are sent as interactive messages with inline approve/reject buttons
  • Approval policies — require approval from a specific user, any team member, or multiple reviewers
  • Timeout — set a maximum wait time; the workflow fails if approval is not received within the window

Paused executions do not consume compute resources while waiting for approval. Only the workflow state is held in memory.

Resume, Cancel, and Retry

Control running and completed executions:

Resume Paused Executions

When a workflow is waiting for approval or paused by an error:

  • Click Approve or Reject from the execution detail page or inbox notification
  • Approved executions continue from the paused step
  • Rejected executions are marked as failed with the rejection reason logged

Cancel Running Workflows

Stop an execution at any point:

  • Graceful cancel — sends a termination signal to the current step, allowing cleanup
  • Force cancel — immediately stops all running containers
  • Cancelled executions are marked with a cancelled status

Retry Failed Executions

Restart from the point of failure:

  • Retry from failed step — re-execute starting at the step that failed, preserving outputs from earlier steps
  • Retry entire workflow — restart the full workflow from the beginning
  • Retry with modified inputs — change input parameters before retrying

Artifacts

Workflow steps can produce artifacts — files generated during execution that are retained after the container is destroyed:

  • Upload artifacts — steps declare output files that are automatically collected
  • Download artifacts — download individual files or a ZIP archive from the execution detail page
  • Cross-step artifacts — later steps can consume artifacts produced by earlier steps
  • Retention — workspaces (and the artifacts inside them) are kept for 24 hours after completion by default per internal/workflows/workspace.go DefaultRetentionHours. Configurable per workflow via runtime_config.retention_hours

Common artifact types: test reports, build binaries, coverage reports, generated documentation, log files.

Cost Tracking

Every execution tracks resource consumption for billing and optimization:

  • Per-step costs — token usage and compute time broken down by individual step
  • Per-execution totals — aggregate cost for the entire workflow run
  • Model breakdown — which AI models were used and how many tokens each consumed
  • Compute breakdown — container runtime duration and resource class for each agent step
  • Trend analysis — compare costs across runs of the same workflow to identify regressions

Cost data is available in real-time during execution and persisted in the execution record after completion.

Cost values in OSS are $0. Token usage and compute time are recorded faithfully, but pricing.CostCalculator is nil in OSS so the Cost column reads as $0 until you wire up a custom calculator. The Enterprise build registers a real calculator that consults provider rate cards. See Billing for how to attach pricing in OSS.

Use the Cost column in execution history to quickly identify expensive runs. Sort by cost descending to find optimization opportunities.