Error Trigger

Description

The Error Trigger is a special trigger that activates a workflow when one or more other workflows encounter a fatal error during execution. It works as a global error-handling mechanism, similar to n8n’s Error Trigger.

Place this node in a dedicated error-handling workflow. When any monitored workflow fails, Floogos automatically invokes that handler workflow with the full context of the failure: error message, stack trace, the node that failed, and the last data payload in circulation before the crash.

---

How It Works

1. A workflow runs and fails (a node throws an exception or crashes)
2. The Floogos engine detects the failure and looks up all active Error Trigger workflows registered for that client
3. It filters by watched_workflow_ids — if empty, the handler fires for any failing workflow
4. The handler workflow is invoked asynchronously with the error context as input data
5. Your error-handling logic runs: send an alert, log to a database, retry via Sub-Workflow, etc.

---

Configuration

Parameter	Type	Required	Description
watched_workflow_ids	workflow_multi_selector	No	Workflows to monitor. Leave empty to catch errors from all client workflows.

A single error-handler workflow can watch multiple specific workflows, or act as a catch-all by leaving the field empty.

---

Output Data

When triggered, the node passes the following payload to the next node:

{
  "error_message": "Cannot read properties of undefined (reading 'price')",
  "error_type": "module_error",
  "error_stack": "TypeError: Cannot read...\n    at Object.<anonymous> (/modules/http/index.js:42:18)",

  "failed_workflow_id": 87,
  "failed_workflow_name": "Process Orders",
  "failed_node": "HTTP_Request",
  "workflow_instance_id": "exec_1714823901234",

  "is_production": true,
  "is_dev": false,
  "timestamp": "2026-04-22T10:34:01.234Z",

  "last_data": {
    "order_id": "ORD-4821",
    "customer_email": "user@example.com",
    "total": 129.99
  },

  "execution_logs": [
    { "node": "Webhook", "status": "ok", "duration_ms": 3 },
    { "node": "HTTP_Request", "status": "error", "error": "Cannot read..." }
  ]
}

Field Reference

Field	Type	Description
error_message	string	Human-readable error message
error_type	string	module_error (node exception) or code_error (script error)
error_stack	string	Full stack trace (null if not available)
failed_workflow_id	number	ID of the workflow that failed
failed_workflow_name	string	Display name of the failed workflow
failed_node	string	Label of the node that caused the error
workflow_instance_id	string	Unique execution ID for correlation with traces
is_production	boolean	Whether the workflow was running in production mode
is_dev	boolean	Whether it was a dev/test execution
timestamp	string	ISO 8601 timestamp of the failure
last_data	object	The data payload at the moment of failure
execution_logs	array	Per-node execution summary up to the point of failure

---

Usage Examples

Example 1 — Slack Alert on Any Failure

A catch-all handler that sends a Slack message whenever any workflow fails.

Error Trigger config:

{
  "label": "Error Trigger",
  "watched_workflow_ids": []
}

Slack message node (using dynamic variables):

❌ Workflow failed: {{@ErrorTrigger.failed_workflow_name}}
Node: {{@ErrorTrigger.failed_node}}
Error: {{@ErrorTrigger.error_message}}
Time: {{@ErrorTrigger.timestamp}}

Full flow:

ErrorTrigger (all workflows)
  → Slack (post to #alerts channel)
  → End

---

Example 2 — Email Alert with Last Data

Catch failures in a specific critical workflow and email the team with the full context.

Error Trigger config:

{
  "label": "Error Trigger",
  "watched_workflow_ids": [42]
}

SendMail node:

To: ops-team@company.com
Subject: [ERROR] {{@ErrorTrigger.failed_workflow_name}} failed
Body:
  Node that failed: {{@ErrorTrigger.failed_node}}
  Error: {{@ErrorTrigger.error_message}}
  Last payload: {{@ErrorTrigger.last_data}}
  Instance: {{@ErrorTrigger.workflow_instance_id}}

Full flow:

ErrorTrigger (workflow ID 42)
  → SendMail (notify ops team)
  → End

---

Example 3 — Log to DataStore + Retry via Sub-Workflow

Store every error in a DataStore table and attempt to re-run the failed workflow.

ErrorTrigger (all workflows)
  → DataStore (insert into error_log table)
  → Decision (is_production == true?)
      → true: Sub-Workflow (re-trigger failed workflow with last_data)
      → false: End

DataStore node config:

{
  "action": "insert",
  "table": "error_log",
  "data": {
    "workflow_id": "{{@ErrorTrigger.failed_workflow_id}}",
    "workflow_name": "{{@ErrorTrigger.failed_workflow_name}}",
    "failed_node": "{{@ErrorTrigger.failed_node}}",
    "error_message": "{{@ErrorTrigger.error_message}}",
    "timestamp": "{{@ErrorTrigger.timestamp}}"
  }
}

---

Example 4 — Multi-Workflow Monitoring with Telegram

Watch two order-processing workflows and send a Telegram alert to the on-call engineer.

Error Trigger config:

{
  "label": "Error Trigger",
  "watched_workflow_ids": [12, 35]
}

ErrorTrigger (workflows 12 and 35)
  → Telegram (send to @oncall_bot)
  → End

Telegram message:

🚨 *Error in {{@ErrorTrigger.failed_workflow_name}}*
Node: `{{@ErrorTrigger.failed_node}}`
Message: {{@ErrorTrigger.error_message}}
Order in flight: {{@ErrorTrigger.last_data.order_id}}

---

Best Practices

• One catch-all + specific handlers: create one generic handler (empty watched_workflow_ids) for alerts, and separate handlers for workflows that need retry logic or special processing.
• Use last_data for context: the payload at the time of failure often contains enough information (order ID, customer email, etc.) to take corrective action without re-querying external systems.
• Use workflow_instance_id for correlation: link error records to the full trace in the Floogos Traces view to debug the root cause.
• Avoid infinite loops: do not watch the error-handler workflow itself, as an error inside it would not retrigger (Floogos prevents direct loops), but it’s good practice to keep handler workflows simple and robust.
• Test in dev mode: use the workflow tester to simulate an error and verify the handler fires correctly before going to production.

---

Notes

• The Error Trigger fires asynchronously — it does not affect the response time of the failed workflow’s caller.
• If multiple workflows are watching the same source workflow, all of them fire simultaneously.
• The handler workflow itself runs as a production workflow (no special dev flag unless the original failure was in dev mode).
• Only fatal errors (unhandled exceptions) trigger this node. Handled errors (caught inside Script nodes, for example) do not fire the Error Trigger.

---

Related Nodes

• Webhook — generic HTTP trigger
• Sub-Workflow — call another workflow to retry the failed operation
• DataStore — persist error records
• SendMail — email alerts
• Slack — Slack alerts