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 the output of another pipeline. When the signal arrives, the trigger dispatches the run and the pipeline takes over, with no manual intervention and no missed windows.

The gap triggers close is timing. A pipeline that reviews pull requests and posts a summary to Slack works when you run it by hand, but with 30 PRs open and a team across three time zones, the PR sits for six hours before someone starts the review. A pipeline that polls staging for deployment readiness has the same gap: it works until a deploy goes out at 2 a.m. and nobody is awake to start it. Your agents already have the ability to do the work; nothing tells them when.

In short

What it does: a trigger starts a pipeline run in response to a specific signal - a manual call, an inbound webhook, a schedule, or another pipeline finishing.
When you would 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 would not: read-only diagnostic steps where the pipeline already decides when to act, or a pipeline you run exactly once. Avoid over-triggering: five triggers firing on overlapping conditions can start more runs than you need, so start with the minimum set.

How it works

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

Manual

Call the API and a run starts. This is the default when you create a pipeline, and it suits one-off runs, development, or precise control over timing.

Webhook

An inbound HTTP POST to a dedicated endpoint with its own URL and a system-generated HMAC secret. Requests are validated with constant-time HMAC comparison before any run starts, and the payload must map through a payload_mapping (JSONPath or JMESPath) so raw external data translates to your input schema. A concurrency limit and payload dedup window prevent duplicate events or rapid bursts from starting 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 suits daily reports, weekly summaries, or any regular cadence; a common pattern pairs 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, which 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, chaining pipelines without glue code: one pipeline's output becomes another's input.

Ongoing

A daemon-style trigger that keeps a pipeline topped up to max_concurrent_runs in-flight runs, starting a new one whenever the pipeline falls below the target. It suits worker-pool style pipelines that 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 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, and an org admin can pause all trigger-initiated runs 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, summarizes them, and posts a digest to the engineering Slack channel. It is a five-minute task, and when she is out sick or on holiday the digest does not happen; last quarter the team missed an authentication-error spike because it did not run for three days while she was away.

After

Priya creates a cron trigger: 0 9 * * 1-5 in the America/New_York timezone. The pipeline 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 after the digest completes. Priya reads the digest instead of starting it, and the team never misses another error spike.

Where it fits in a pipeline

Triggers are the first step in the pipeline lifecycle, 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. Take the product tour to see triggers in action, or use the contact page to talk to us about wiring up triggers for your own pipelines.