Triggers

A trigger decides when a workflow runs. With a cluster connected through the connector, you can attach one or more triggers to a workflow and dagweave fires the run for you on your cluster. You then watch the run in the executions view, with its logs and result. Triggers run workflows on your cluster, so they need the connector and a plan that includes it.

A workflow can have zero, one, or several triggers. If you have more than one connected cluster, you choose which one a trigger runs on. Every trigger reports when it last fired and its last error, so a trigger that quietly stopped working is visible.

Manual

The simplest trigger is a button. Open the workflow in dagweave and press run. dagweave compiles the current graph, submits it through the connector, and shows you the run. This is the fastest way to test a change without wiring anything up.

Cron

A cron trigger runs the workflow on a schedule you set in the dagweave UI. It behaves like a CronWorkflow, but you manage the schedule from dagweave instead of editing a manifest. Set the cron expression, pick the cluster, and dagweave fires each run when the schedule comes due.

Deploy as a native CronWorkflow

A cron trigger keeps the schedule inside dagweave. If you would rather hand the schedule to the cluster and let it run there on its own, build the workflow as a CronWorkflow and deploy it.

Set the workflow kind to CronWorkflow. Starting the canvas from a Schedule trigger does that for you, or you can pick CronWorkflow under Kind in the workflow settings. The settings panel then takes the cron expression and a timezone. Below those sit the CronWorkflow’s own knobs: the concurrency policy (allow overlapping runs, skip a run while the last one is still going, or replace it), a starting deadline that skips a run missed by more than that many seconds, how many successful and failed runs the cluster keeps, and whether the schedule starts active or suspended.

On a CronWorkflow canvas the primary button becomes Deploy schedule instead of Run. Press it and dagweave compiles the canvas, applies any WorkflowTemplates it references so the cluster can resolve them, then applies the CronWorkflow itself. Argo Workflows owns the schedule after that and fires each run, exactly like a CronWorkflow you applied by hand. You need a connector that is enrolled and online; with none connected the button opens the connect-your-cluster flow instead. The editor deploys through your first online connector into the argo namespace.

Deploying a schedule does not create a run in dagweave, because Argo fires those runs, not dagweave. They are still recorded: the connector watches every Workflow object in the namespaces its ArgoConnection covers, so a native CronWorkflow’s children arrive as runs you did not start. Those get their own section of the executions view, below the history table and outside the phase tabs, and they fire the same failure alert as any run dagweave dispatched. Per-step logs are the exception, because the log query is keyed on a workflow id an adopted run does not have.

Use a cron trigger when you want dagweave to own the schedule and fire the runs. Deploy a native CronWorkflow when you want the schedule to live in the cluster on its own.

Webhook

A webhook trigger gives you a URL. Post to it and the workflow runs. This is how you kick off a run from an external system such as a CI job or another service. The endpoint is secured, so only callers with the right secret can fire it, and an HMAC-signed variant is available if the caller signs its requests.

GitHub

A GitHub trigger runs the workflow when a matching event arrives from GitHub. You match on the repository, the event, and the branch. Supported events are a push, a pull request, and a tag. Deliveries are authenticated by GitHub’s shared webhook secret, so only real GitHub events fire the trigger.

AWS SNS

An SNS trigger runs the workflow when a message arrives on an AWS SNS topic. Give it the topic’s ARN. That field is required, and a trigger without one is refused rather than left open.

Two checks run on every notification, and it takes both. dagweave verifies the message signature, which proves an AWS SNS sent it. Every AWS account signs with the same sns.<region>.amazonaws.com certificates, though, so a good signature on its own only says that some account’s topic did. The ARN you bound is what says it was yours: dagweave compares it against the message’s own TopicArn and drops anything that does not match.

Run provenance

Every run records which trigger started it. When you look at a workflow’s history you can tell a manual run from a cron run, a webhook run, a GitHub run, or an SNS run, so you always know why a given run happened.

What is coming

The trigger picker offers manual, cron, webhook, GitHub, and AWS SNS. There is a sixth, s3, which fires on an S3 event notification routed through SNS. The API accepts it today and the picker does not offer it yet, so creating one means posting to POST /api/triggers with "type": "s3", along with the workflowId, connectorId and namespace the other types need. That route takes your signed-in session rather than an API token. We add event sources one at a time, with the same focus on a clean setup flow, a clear view of what ran, and security first. Other AWS message queues are the likely next one.