Executions & Logs

Every time a workflow runs, Voodflow creates a detailed Execution record that captures the full state of the run — inputs, outputs, timing, variables, and errors at both the workflow and per-node level.

Execution Lifecycle

pending → running → success
                 → failed
                 → cancelled

Status	Description
pending	Job dispatched to queue, not yet started
running	Actively executing nodes
success	All nodes completed without error
failed	One or more nodes failed and no error recovery path handled it
cancelled	Manually cancelled by a user

Execution Record Fields

Field	Type	Description
id	integer	Unique execution ID
workflow_id	integer	Parent workflow
status	enum	Current status
trigger_type	string	schedule, event, webhook, manual
workflow_version	string	Snapshot of the workflow at execution time
environment	string	production, staging, local
retry_attempt	integer	0 = first attempt, 1+ = retry
started_at	datetime	Execution start time
finished_at	datetime	Execution end time
input_context	json	The trigger payload that started the execution
context	json	Final context state (vars, node results, errors)

Per-Node Execution Records

Each node execution is recorded in voodflow_execution_nodes:

Field	Description
node_id	Reference to the node definition
node_type	e.g. http_request, send_mail_node
status	success, failed, skipped
input	Data this node received
output	Data this node produced
started_at	Node execution start
finished_at	Node execution end
duration_ms	Computed duration in milliseconds
error_message	Error text if status = failed
retry_count	How many times this node was retried

Browsing Executions

Navigate to Voodflow → Executions to see a paginated table of all executions with:

• Workflow name
• Status badge
• Trigger type
• Start time and duration
• Quick link to per-node details

Click any execution row to drill into the Execution Detail view, which shows a timeline of every node with expandable input/output panels.

Log Entries

ExecutionLogEntry records are structured log lines emitted during execution:

execution_id | node_id | level | message | context | created_at

Levels: debug, info, warning, error

These logs are visible in the Execution Detail view and queryable via the Eloquent model:

$execution->logs()->where('level', 'error')->get();

Log Retention

Execution records and log entries can be automatically pruned to control database growth. This is done via the voodflow:cleanup-logs command:

php artisan voodflow:cleanup-logs

Default retention is taken from VoodflowSettings->log_retention_days. In addition, each workflow can override the retention window via workflow.metadata['log_retention_days'] (so you can keep logs longer for important workflows, and shorter for low-value ones).

You can also run targeted cleanup:

# Use a specific retention window (override the default)
php artisan voodflow:cleanup-logs --days=30

# Cleanup only one workflow by ID
php artisan voodflow:cleanup-logs --workflow=123

See Log Retention for a full retention policy guide, including GDPR considerations.

Retry Logic

Failed executions can be retried:

1. Automatic retry (per workflow) — Voodflow reads the retry configuration from workflow.metadata.retry_policy and uses the queue worker retries to re-attempt the same Execution when a retryable error occurs (network / timeout / rate limit). Automatic retry is driven by the job being retried by the queue worker; it does not depend on the presence of a Catch node. After retries are exhausted (or for non-retryable errors), the execution is marked as failed and (if a Catch node is connected after the failing step) the workflow can route to an error/recovery branch.
2. Manual retry / Resume — in the Execution detail view, click Resume Execution to re-run from where it failed (this increments retry_attempt).

Catch behavior (success vs error)

Catch is designed to sit immediately after a node that may fail (e.g. send_webhook) and route to one of two outputs:

• success: upstream node succeeded (normal pass-through)
• error: upstream node failed (Catch enriches output with _caught_error when enabled)

Important: Voodflow treats Catch as a gate based on the incoming payload. It will not re-catch historical errors from earlier attempts once the upstream node succeeds (e.g. after a manual resume).

Manual vs Auto counters

• retry_attempt counts manual resume attempts (0 = never resumed, 1+ = resumed by a user).
• Automatic queue retries are tracked in context.meta:
  • queue_attempt: 0-based attempt index (0 on first run, 1 on first automatic retry, ...)
  • queue_attempt_number: 1-based attempt number (Laravel queue)
  • queue_laravel_attempt_number: raw Laravel attempts() value (diagnostics)
  • queue_max_attempts: configured max attempts for this job
  • queue_next_attempt_number and queue_next_delay_ms: when an auto-retry is scheduled

Manual resume does not create a new Execution record — it resumes the same execution and increments retry_attempt.

Context Object Structure

The context JSON column contains the full execution state:

{
  "meta": {
    "workflow_id": 42,
    "started_at": "2025-03-16T08:00:00Z"
  },
  "vars": {
    "my_variable": "some_value"
  },
  "nodes": {
    "node_uuid_1": { "output": { ... }, "status": "success" },
    "node_uuid_2": { "output": { ... }, "status": "success" }
  },
  "errors": []
}