Execution History and Logs

Table of Contents:

• Browsing Execution History
• Execution Status: Success, Error, Skipped
• Step-Level Log Details — Diagnosing Errors
• Re-running a Failed Workflow

---

Sembot records every workflow execution — when it ran, how long it took, whether it succeeded, and exactly what each block did. This lets you verify that your automation is working correctly, diagnose errors, and make an informed decision about re-running.

---

Browsing Execution History

Execution history is available directly from the workflow editor — click the "Execution History" button (clock icon) in the top toolbar. A panel will open on the right side listing all previous executions of this workflow.

What you see in the execution list:

Field	Description
Status	Color-coded badge: success, error, running, cancelled
Start Time	When the workflow ran (date and time)
Duration	How many milliseconds the execution took (e.g. 1,240 ms)
Trigger Type	What started the workflow: schedule, webhook, manual
Error Message	If the workflow failed — a brief description of the error

The list refreshes automatically every 10 seconds — no need to manually refresh while waiting for the current execution to finish. You can also click the "Refresh" button (circular arrow icon) at any time.

Clicking any item in the list opens the detailed view for that execution.

📸 [SCREEN: "Execution History" panel on the right side of the editor — list of executions with color-coded status badges, dates, durations, and trigger types]

---

Execution Status: Success, Error, Skipped

Each execution and each block within an execution has an assigned status.

Execution statuses (workflow level):

Status	Color	Description
success	Green	All blocks executed successfully
failed	Red	At least one block failed and the workflow stopped
running	Blue	The workflow is currently in progress
cancelled	Gray	The execution was manually stopped by the user

Block statuses (individual node level):

Status	Dot	Description
success	Green	The block executed successfully and returned data
error	Red	The block failed — details available on click
running	Blue	The block is currently being executed
skipped	Gray	The block was not executed because an If condition routed the flow down a different path

A block with skipped status is not an error — it is the intended behavior of the workflow when a given conditional branch is inactive.

📸 [SCREEN: detailed execution view — block timeline with color-coded dots next to each node; green, red, and gray blocks visible]

---

Step-Level Log Details — Diagnosing Errors

Clicking a specific block on the execution timeline expands its details. This is the primary tool for diagnosing issues.

What you see when a block is expanded:

Section	Contents
Error	Error message (visible only when the block failed)
Input Data	Parameters passed to the block — variable values from previous blocks already substituted
Output Data	Data returned by the block — what subsequent blocks will receive
Execution Time	How many milliseconds this specific block took

How to use logs for diagnosis:

1. Open the execution history and click an execution with "Error" status.
2. Find the block with a red dot on the timeline.
3. Click that block — the section with the error message will expand.
4. Check the Input Data section — were the variables substituted correctly? Do the values look as expected?
5. If the previous block succeeded, check its Output Data — does it contain the fields you expect, under the right names?

Common error causes identified through logs:

• A block received no data because the previous block returned an empty list
• A variable name in an expression doesn't match the field in the output data (typo)
• An external API returned an error — visible in the error message of the HTTP Request block
• Timeout — a block ran too long and the system terminated it
• An AI Agent did not respond in the expected format

Note: Input and output data for blocks may be truncated if very large — the system shows a maximum of 5,000 characters. For very large responses (e.g. large datasets from Google Ads), some content will be marked as _truncated: true.

📸 [SCREEN: expanded block with red dot — error message visible at the top, followed by "Input Data" and "Output Data" sections with JSON values]

---

Re-running a Failed Workflow

Sembot does not have a "resume from failure point" button — every re-run starts from the beginning. You have several ways to trigger a re-run.

Option 1 — From the workflow list:

In the main Workflow → List panel, each workflow has a "Run Now" option in the context menu (three dots). This runs the workflow immediately, regardless of its schedule.

Option 2 — From the editor:

Click the "Run Workflow" button (play icon) in the top toolbar of the editor. The workflow Inspector opens on the right side with a live view of the current execution.

Option 3 — Configure automatic retries for a block:

If a workflow regularly fails on a specific block (e.g. an external API is intermittently unavailable), you can configure automatic retries for that block — without needing to trigger it manually.

Click the block in the editor → properties panel on the right → advanced settings section:

Option	What it does
Continue on Error	The workflow does not stop when this block fails — it continues to subsequent blocks
Retry on Error	Automatically retries this block if it fails
Max Retries	How many times to retry (1 – 5)
Timeout (seconds)	Maximum execution time for this block (exceeded = error)

Example configuration for an unstable API:

Retry on Error:      ✓ Enabled
Max Retries:         3
Continue on Error:   ✗ Disabled

Result: if the API does not respond, Sembot will try 3 more times. Only if all 4 attempts fail will the workflow stop with an error.

Retry settings are configured per block individually. A data-fetching block can have 3 retries, while an HTTP Request block can have just 1.

📸 [SCREEN: block properties panel with expanded advanced settings section — "Continue on Error" and "Retry on Error" toggles visible, along with max retries and timeout fields]