Workflow run and performance controls

Prepare a test request, execute a saved workflow, and investigate outcomes, timing, and individual steps.

7 min readUpdated Sep 6, 2026

Step-by-step guidance.

Before you start

Open the named screen in Rumata. Available controls may depend on your account, permissions, and resource state.

Choose Run in the editor toolbar to open a request form. Opening the form does not execute the workflow.

Control	What it does
Request / JSON	Choose an HTTP-style request form or enter the complete trigger input as JSON.
Method	Set the test request method: GET, POST, PUT, PATCH, or DELETE. Check it against your trigger; the form starts with POST.
Path params	Supply values for named placeholders in the workflow route, when present.
Query params / Headers → plus	Add a name/value pair to the test request. The trash icon removes that pair.
Body (JSON)	Enter the request body as valid JSON, for example {"message":"hello"}.
Trigger input (JSON)	In JSON mode, enter the complete input object instead of assembling it from request fields.
Workflow default / Fast / Durable	Use the saved execution setting or request an engine for this one run. Read the explanation below the selector: a Fast choice can fall back to Durable.
Run workflow	Execute the saved workflow with this input. This can write data, call services, and consume credits. Save a new workflow first. If an unsaved-changes warning appears, choose Save before running to test those changes.
Close	Dismiss the panel. Closing the panel does not cancel a workflow already running.

The engine response and individual step results help explain what happened. Missing details may not have been retained.

Control	What it does
Engine response	Read the returned result or the run identifier, depending on the response mode.
Nodes → step row	Expand or collapse the step’s received input, passed-on output, and any error.
Agent execution details	Inspect recorded tool calls, parameters, results, duplicate-call skips, turn count, and cost when available.
Executor and timing badges	Check which engine actually ran and compare server processing with the full request round trip.

Choose the Runs tab to inspect earlier executions. Opening an existing run does not execute it again.

Control	What it does
Refresh run history	Reload the list. It also refreshes automatically while the view is open.
Run row	Open that run’s details and show recorded step statuses on the canvas.
Previous / Next	Move through history pages of up to 20 runs.
Back to runs	Return to the history list and clear the selected run’s graph overlay.
Step on the history canvas / execution-log row	Select or expand a step to inspect its recorded data. The history canvas is for inspection.
Resize divider	Adjust the space between the graph and the history panel.
Execution timeline	Read total elapsed time, time with steps active, time outside steps, and overlapping parallel work. Duration-only history has less timing detail.
Final result	Inspect the final stored output when available.

The Performance tab summarizes retained executions. The same range controls appear in the overview’s workflow charts.

Control	What it does
Hourly / Daily	Group measurements by hour or day. Switching resets the window to the last 24 hours or last 7 days respectively.
Moving time window	Hourly offers 1 hour, 6 hours, 24 hours, or 7 days. Daily offers 7, 30, or 90 days.
Refresh performance	Fetch the selected range again. The view also refreshes automatically.
Chart point hover	Inspect values for that time bucket. A blank or unavailable metric is not evidence of zero usage.
Runs / Success rate / Average execution / P95 execution	Read volume, reliability, average duration, and the slower end of the duration distribution.