Workspace Events Trigger

The Workspace Events trigger runs a workflow when a workspace alert rule fires on any other workflow in the same workspace — consecutive failures, failure-rate spikes, error counts, latency thresholds/spikes, or cost thresholds. It reuses the same rule engine that powers workspace notifications, but exposes those events as a composable trigger you can build on.

Unlike webhook triggers, there is no URL to register: Zelaxy evaluates your workspace's run history on a schedule (about once per minute) and runs this workflow once per firing event.

Overview

When to Use

• Auto-remediate: restart, roll back, or re-run a workflow when it starts failing
• Escalate: page a human, open a ticket, or post to a channel when failure rates spike
• Observe: capture every failing run in the workspace into a log, warehouse, or dashboard
• Guardrails: react when a workflow's cost or latency crosses a threshold

Configuration

Event types

no_activity alerts have no triggering run, so they are delivered through workspace notification channels rather than this poll-driven trigger.

How It Works

1. Add the Workspace Events trigger to a workflow and choose an Event type.
2. Activate the workflow. Zelaxy begins evaluating the workspace's run history on a schedule.
3. The first poll only seeds the cursor — it records the runs that already exist and triggers nothing. This prevents replaying history when you connect the trigger.
4. As other workflows in the workspace complete runs, each firing event runs this workflow once, oldest first.
5. The workflow that hosts this trigger is always excluded from evaluation, so reacting to an event can never re-trigger itself (no infinite loop).

Event Fields

The poller flattens each event's fields to the top level of the trigger block's output, so you can reference them directly.

Example event

{
  "rule_type": "consecutive_failures",
  "reason": "Last 3 runs all failed",
  "workflow_id": "wf_abc123",
  "workflow_name": "Nightly sync",
  "execution_id": "exec_xyz789",
  "status": "error",
  "level": "error",
  "trigger": "schedule",
  "duration_ms": 4200,
  "cost": 0.0123,
  "started_at": "2024-01-15T13:14:15.000Z",
  "ended_at": "2024-01-15T13:14:19.200Z"
}

Accessing Data in Downstream Blocks

Reference the flattened fields with the {{BlockName.field}} syntax. The block name is the label shown on the canvas (default: Workspace Events 1).

{{Workspace Events 1.rule_type}}        → "consecutive_failures"
{{Workspace Events 1.reason}}           → "Last 3 runs all failed"
{{Workspace Events 1.workflow_name}}    → "Nightly sync"
{{Workspace Events 1.workflow_id}}      → "wf_abc123"
{{Workspace Events 1.status}}           → "error"
{{Workspace Events 1.cost}}             → 0.0123

Example: Alert on repeated failures

Workflow:

[Workspace Events 1 (consecutive_failures)] → [Agent: Summarize failure] → [Slack: Post to #ops]

Whenever any workflow in the workspace fails 3 times in a row, this workflow runs. Pass the event into the Agent block:

Workflow "{{Workspace Events 1.workflow_name}}" is failing: {{Workspace Events 1.reason}}.
Last execution: {{Workspace Events 1.execution_id}} (trigger: {{Workspace Events 1.trigger}}).

Tips

• Scope it — set Watched workflow IDs to react to only a few critical workflows instead of the whole workspace.
• Tune thresholds — the Thresholds (JSON) field overrides only the keys you set; everything else keeps the alert-engine default.
• any is a firehose — every completed run fires an event. Filter downstream with a Condition block on status or workflow_id, or prefer a specific event type.
• No replay — connecting the trigger never fires for runs that already happened; only new runs count.
• Self-trigger safe — the hosting workflow is always excluded, so a remediation workflow reacting to failures never triggers itself.