Skip to main content
Sensors are the decision-making components in Argo Events. They subscribe to an EventBus (NATS by default), evaluate incoming events against declared dependencies, and execute triggers when the required conditions are met. This article explains what a Sensor does, details key spec fields, and walks through example Sensor specifications and usage patterns.

What a Sensor does

  • Subscribes to one or more sources on the EventBus.
  • Waits until one or more specified events occur (individual or combinations).
  • When dependencies and conditions are satisfied, executes one or more triggers (for example, starts a workflow, sends an HTTP request, or creates a Kubernetes resource).

Sensor spec: key concepts

For more background, see Argo Events Sensors.

Example: WebhookSensor

Assume a Sensor named webhook-sensor. By default it uses the EventBus named default; you can override it with spec.eventBusName. Think of a Sensor as tuning into a radio channel (the EventBus) and listening for broadcasts (events). The Sensor spec centers around dependencies (the “if” side) and triggers (the “then” side).

Dependencies

dependencies is the “if” part. The Sensor remains idle until the dependencies are satisfied. Each dependency includes:
  • name: a local identifier used to reference this event later in parameters or conditions.
  • eventSourceName: the configured event source (for example, webhook).
  • eventName: the specific event produced by the event source (for example, example-webhook).

Triggers

triggers define the actions executed after dependencies/conditions are satisfied. Triggers support multiple adapters (HTTP, Kubernetes, Argo Workflows, etc.). In the example below the trigger creates a Kubernetes Pod via the Kubernetes API (k8s.operation: create) using an inline resource template.

Parameters: mapping event data into trigger templates

parameters let you inject values from incoming events into trigger resource templates.
  • src describes where to read data from: dependencyName and dataKey (a path inside the event payload, e.g., body.message).
  • dest is the YAML/JSON path in the target template where the value will be injected; use numeric indices for arrays (for example, spec.containers.0.args.0).
When specifying destination paths for parameters, use numeric indices for array positions (for example, .containers.0.args.0). The textual description like “firstIndex” is conceptual — the actual path must use numbers.

Sensor YAML example (creates a Pod that echoes a message from the event)

Triggering the Sensor with an example POST

Use an HTTP POST to the webhook event source (adjust the URL/port to match your environment):
After the Sensor creates the Pod, the container spec will show the injected argument:
This demonstrates how event payload fields can be mapped into the resource template created by the Sensor.

Trigger conditions (combining dependencies)

  • A Sensor can declare multiple dependencies. By default (when conditions is omitted) all dependencies are required (logical AND).
  • Use conditions on individual trigger templates to control when each trigger runs. Conditions support boolean expressions with &&, ||, and parentheses.
  • Reference dependencies by their name in the boolean expression.

Example: multiple dependencies with condition-based triggers

Common condition patterns:
  • "X" — trigger runs when X occurs
  • "Y" — trigger runs when Y occurs
  • "X && Y" — both X and Y must have occurred
  • "X || Y" — either X or Y
  • "(X || Y) && Z" — Z plus either X or Y
If you omit conditions, the Sensor treats all listed dependencies as required (logical AND). Ensure you use straight quotes (”) in YAML strings — avoid curly quotes.

Summary

  • Sensors listen to an EventBus, evaluate dependencies, and execute triggers when conditions are met.
  • Use parameters to map event payload fields into trigger templates (remember numeric indices for arrays).
  • Use conditions for flexible boolean logic across multiple dependencies to control individual triggers.

Watch Video