Inspect a past run

An execution is one run of a project. It starts when someone clicks Run in the Builder, when a trigger fires (a cron tick, an API webhook, a human trigger, a deployed page CTA), or when another node resumes a paused HumanQuery. It ends when every reachable node has produced an output, been skipped, or failed.

Every execution is stored on the server with the input that started it, each node's status, each node's output, any error that was raised. You can come back to any past execution later and see exactly what happened.

The Executions page

The dashboard has a dedicated Executions page in the sidebar. It shows a paginated list of recent runs, sorted by most recent first. Each row has:

• A short execution ID.
• The project the execution ran against, with a link to the project.
• A trigger label (Manual when you clicked Run, otherwise the node type that fired it: Cron, ApiPost, HumanTrigger, etc.).
• The start time (relative, like "2 minutes ago") and completion time if it finished.
• A status badge: pending, running, completed, failed, waiting_for_input, paused, or cancelled.
• The execution cost in USD (for runs that consumed LLM tokens or paid API calls).

Click a row to expand it. The expanded view shows the execution's metadata, any top-level error, per-node statuses, and each node's final output. From there, a View in Editor button opens the project at that execution so you can see the state directly on the graph.

Viewing an execution on the graph

Click View in Editor on any past execution, or navigate to /projects/<id>?executionId=<uuid> directly. The project opens with the execution's state layered onto the graph: each node shows its recorded output inline, and you can click any node to see the exact data that flowed through.

If the execution is still running or waiting_for_input, the view polls for updates so you see new outputs as they arrive. For finished executions, the state is static.

Execution statuses

Each execution has one of seven statuses. The distinction matters for debugging.

• pending: the execution was registered but has not started running yet.
• running: actively executing nodes.
• waiting_for_input: the execution hit a HumanQuery and is suspended until someone answers the form. See Put a human in the loop.
• paused: execution was explicitly paused.
• completed: all reachable nodes finished (successfully or skipped via null propagation) without raising a fatal error.
• failed: a node raised an error that was not caught. The error message is surfaced on the execution row.
• cancelled: someone clicked Cancel (from the Executions page or from the Builder) on a running or waiting execution.

Note that an execution can be completed even if some of its nodes skipped. Skipped and failed are different things:

• Skipped nodes did not run because one of their required inputs received null. This is how branching and null propagation work. Skipped is normal, not an error.
• Failed nodes ran and raised an error. Their output is null and the error is recorded on the execution.

Durable execution

Weft programs survive crashes. Under the hood, executions run through Restate, a durable execution engine: every node output is persisted the moment it is produced, every suspension point is recorded. If the server dies mid-execution, the run resumes from the last recorded checkpoint when the server comes back. You do not lose work, you do not double-run a side effect, you do not have to re-enter a form a human already filled.

This is the same mechanism that lets HumanQuery wait for days at a time. A form waiting for Approve and a project mid-restart are the same kind of suspended state, from Restate's point of view. The executor picks up where it left off either way.

Debugging a failed execution

When something goes wrong, the Executions page is where you look. The flow usually goes:

1. Open the Executions page. Find the failed execution in the list.
2. Expand the row. Read the top-level error if there is one, and scan the per-node statuses to find the red one.
3. Click View in Editor to open the project on the graph at that execution's state. The failing node shows its inputs and its recorded error inline.
4. Fix the code, or change the input that triggered the bug, and click Run to try again.

If the bug was external (an API was down, a credential expired, a rate limit was hit), fix the underlying issue and just run again. Weft does not penalize you for external failures.

For executions that are currently running or waiting, the detail view has a Refresh State button to pull the latest state and a Cancel button to stop them.

Project history

The project editor has a History panel with past versions of the project. Auto-saved versions are created every ten minutes if the code has changed, and you can save manual versions with a label at any time. From the History panel you can view a past version and restore it into the current project.

History is separate from executions. History tracks what the project was; executions track what happened when the project ran. There is no feature today to re-run a past execution against an older version of the project; if you need that, restore the version first, then run.