Feature Spotlight: How triggers start your pipelines on demand or on a schedule

You configure a trigger to start a pipeline run in response to a signal - a webhook from GitHub, a cron schedule, a connector changing state, or even the output of another pipeline. When the signal arrives, the trigger dispatches the run and the pipeline takes over. No manual intervention, no timers someone has to remember, no missed windows.

In short

• What it does: a trigger starts a pipeline run in response to a specific signal, whether that is a manual call, an inbound webhook, a schedule, or another pipeline finishing.
• When you'd use it: any pipeline that needs to run without a person pressing a button, on a schedule, or in response to an external event.
• When you wouldn't: for read-only diagnostic steps where the pipeline itself already decides when to act, or for one-off experiments you run once and never automate.
• Every activation creates a TriggerEvent record so you can audit what fired, when, and whether it succeeded.

The problem it solves

Say you have a pipeline that reviews pull requests and posts a summary to Slack. It works great when you run it by hand. But you have 30 PRs open, and your team is in three time zones. By the time someone remembers to kick off the review pipeline, the PR has been sitting for six hours and the author has already context-switched to something else. The pipeline is useful, but only if it runs at the right time.

Or consider a pipeline that polls your staging environment for deployment readiness. Right now someone SSHes in, checks the logs, and manually starts the pipeline if everything looks clean. That works until a deploy goes out at 2 a.m. and nobody is awake to check. The pipeline has the logic to do the job, but there is no mechanism to start it at the moment it matters.

Your agents already have the ability to do the work. The gap is that nothing tells them when to do it. Triggers fill that gap: they turn a pipeline from a tool you run by hand into a system that starts itself.

How it works

A trigger is a configuration attached to a pipeline. Each pipeline can have multiple triggers, and each trigger fires a run when its conditions are met. Modulo supports six trigger types, each designed for a different starting condition.

Manual

The simplest trigger: you call the API and a run starts. This is the default when you create a pipeline. Use it for one-off runs, development, or when you want to control exactly when a run happens.

Webhook

An inbound HTTP POST to a dedicated endpoint. Each webhook trigger gets its own URL and a system-generated HMAC secret. Inbound requests are validated with constant-time HMAC comparison before any run starts. The payload is required to map through a payload_mapping (JSONPath or JMESPath) so raw external data translates cleanly to your pipeline's input schema. Flood protection and deduplication are built in: you can set a concurrency limit and a payload dedup window so duplicate events or rapid bursts do not spin up duplicate runs.

Cron

Schedule-based triggers evaluated against a named IANA timezone. You set a cron expression and a timezone, and the next fire time is persisted in UTC. This is the right choice for daily reports, weekly summaries, or anything that runs on a regular cadence. A common pattern is pairing a cron trigger with a connector that pulls fresh data at the scheduled moment.

Polling

Polls a connector at a configurable interval and starts a run when a condition is met. You define a poll_query and a condition_expression that evaluate the connector's state. This is useful when you cannot push events to Modulo and need to check an external system periodically.

Agent signal

Fired by the output of another pipeline. When pipeline A completes, it can signal pipeline B to start. This chains pipelines together without glue code: one pipeline's output becomes another's input, and the trigger handles the handoff.

Ongoing

A daemon-style trigger that keeps a pipeline topped up to max_concurrent_runs in-flight runs. If the pipeline has fewer than the target number of active runs, the trigger starts a new one. This is the right pattern for worker-pool style pipelines where you want continuous throughput. A daily spend limit is required, and the trigger auto-deactivates after a configurable number of consecutive runs that produce no delivery.

{
  "type": "cron",
  "config": {
    "schedule": "0 9 * * 1-5",
    "timezone": "America/New_York",
    "input_template": { "task": "daily-report", "channel": "#eng-updates" }
  }
}

Every trigger activation creates a TriggerEvent record with the trigger ID, type, a hash of the raw payload (never the payload itself, which may contain secrets), the validation result, and the run ID. Operators can view the log and replay any logged event. An org admin can also pause all trigger-initiated runs across the organization without deleting individual triggers.

Journey example: before and after

Before

Priya runs the engineering team at a mid-sized SaaS company. Every morning at 9 a.m. she manually kicks off a pipeline that pulls overnight error logs from the monitoring system, summarizes them, and posts a digest to the engineering Slack channel. It is a five-minute task, but it is five minutes every single morning, and when she is out sick or on holiday the digest simply does not happen. Last quarter the team missed a spike in authentication errors because the digest did not run for three days while Priya was away.

After

Priya creates a cron trigger on the pipeline: 0 9 * * 1-5 in the America/New_York timezone. The pipeline now runs every weekday at 9 a.m. without anyone pressing a button. When the team adds a second pipeline that checks staging readiness, she wires it to an agent signal trigger so it starts automatically after the error digest completes. The digest still runs at 9 a.m., and the staging check follows right after. Priya spends her mornings reading the digest instead of starting it, and the team never misses another error spike.

When to use it vs. when not to

Use triggers when a pipeline needs to start in response to a specific event or condition: a webhook arriving, a schedule firing, a connector changing state, or another pipeline finishing. Triggers are also the right choice when you want auditability: every activation is logged, so you can trace exactly what started a run and why.

Do not use triggers for pipelines you want to run exactly once for a one-off experiment. Manual triggers exist for that purpose. Also avoid over-triggering: a pipeline with five triggers that all fire on overlapping conditions can spin up more runs than you need. Start with the minimum set of triggers that covers your actual use case, and add more as the pattern becomes clear.

Where it fits in a pipeline

Triggers are the first step in the pipeline lifecycle. They sit upstream of gates and HITL checkpoints: a trigger starts the run, agents do the work, gates validate the output, and checkpoints add human judgment where needed. For the gate types that run before a person ever looks, see HITL gates. For the broader design philosophy behind how Modulo treats autonomy, see the principles of Modulo.

Go deeper

Read the triggers docs for the full configuration reference, or the related docs on pipelines and connectors. Try the hosted demo at demo.modulo.run, or use the contact page to talk to us about wiring up triggers for your own pipelines.