In this lesson you’ll create an Argo Events Sensor that listens to a webhook EventSource and triggers an Argo Workflow. Sensors can trigger many target resources — for example Argo Workflows, AWS Lambda, HTTP endpoints, or generic Kubernetes objects. If a built-in trigger doesn’t meet your needs, Argo Events provides extension points to implement a custom trigger.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.


Sensor concepts: dependencies and triggers
- A Sensor lists one or more dependencies. Each dependency references an EventSource by name and a named event defined in that EventSource (the event name).
- When a dependency is satisfied (an event is published), the Sensor evaluates any dependency expressions (if configured) and then executes the configured trigger(s).
webhook and the event my-webhook:
EventSource names and event names are defined in your EventSource manifest. Use
eventSourceName to reference the EventSource metadata.name and eventName to reference the specific event key under spec.- The EventSource resource contains the top-level name (EventSource metadata.name) and under its
specyou will see one or more events (each with its own name). Example (abridged):
- In the Sensor dependency above, use
eventSourceName: webhookandeventName: my-webhook. The Sensor will only react when that specific event is emitted.
Triggering an Argo Workflow from a Sensor
Below is a Sensor trigger configured to submit an Argo Workflow when the dependency matches. The trigger uses theargoWorkflow trigger type and embeds the Workflow manifest as the resource.
Prepare to send an event to the webhook EventSource
- Confirm the EventSource service exists in the
argo-eventsnamespace and get its service name and port. - Port-forward the EventSource service to localhost so you can POST to it.
/push):
Inspecting logs and the event flow
- The EventSource pod logs will show the webhook receiving the request, validating the route, and publishing the event to the EventBus.
- The Sensor logs show subscription to the EventBus and then the attempt to execute the trigger when an event arrives.
Why the trigger failed
The Sensor attempted to create an Argo Workflow in theargo namespace, but the service account used by the Sensor (system:serviceaccount:argo-events:default in this example) does not have RBAC permissions to create workflows.argoproj.io in the argo namespace. This caused the PermissionDenied error in the Sensor logs.
Ensure the service account configured for the Sensor (via spec.template.serviceAccountName or in the Sensor controller pod) has appropriate RBAC permissions to create the target resources (Argo Workflows or Kubernetes objects) in the target namespace.
Solution outline (RBAC and service account)
Steps to resolve:- Create or select a service account that has a Role or ClusterRole with permissions to create/submit the target resource (e.g.,
workflows.argoproj.io) in the target namespace. - Create a RoleBinding or ClusterRoleBinding that binds the Role/ClusterRole to the service account.
- Configure your Sensor to use that service account, for example via
spec.template.serviceAccountName: <name>. - Re-trigger the webhook; the Sensor should now be able to submit the Workflow.
| Resource Type | Use Case | Example |
|---|---|---|
| Role / RoleBinding | Grant namespace-scoped permissions for Sensor service account | Grant create on workflows.argoproj.io in argo namespace |
| ClusterRole / ClusterRoleBinding | Grant cluster-scoped permissions if needed across namespaces | Grant create on workflows.argoproj.io cluster-wide |
| ServiceAccount | Token identity used by Sensor to act against the API server | create-pod-sa used by Sensor template |
Kubernetes object trigger example (create a Pod)
Triggers can also create generic Kubernetes objects (Pods, Deployments, Jobs, etc.). For such triggers, grant the service account the required permissions for the relevant Kubernetes API resources.
k8s trigger:
Next steps
- Create a service account and bind the appropriate Role/ClusterRole to it (use RoleBinding or ClusterRoleBinding).
- Update your Sensor to reference the service account via
spec.template.serviceAccountName. - Re-submit the event to your webhook and watch the Sensor create the target resource (Workflow or Pod).
- Consult the Argo Events documentation for advanced trigger parameterization and transformations.