Skip to main content
A trigger starts agent work without a person opening a new turn. Manage triggers under the team’s Settings → Triggers, or ask an agent to create or update one. Check for an existing trigger for the same job before adding another.

​
Schedules use UTC

Cron schedules use standard 5-field expressions evaluated in UTC, not the computer’s local time. Convert the time you intend and review the next runs. For example, 09:00 in a fixed UTC+8 timezone is 01:00 UTC, so a daily run uses 0 1 * * *. For timezones with daylight saving, revisit the UTC schedule when the offset changes. Invalid expressions are rejected. Self-hosted cron work also requires the backend scheduler to be enabled.

​
Webhooks

A webhook trigger accepts HTTP POST at its generated URL. Supply its secret in X-Webhook-Secret; a missing or wrong secret is rejected. Use the values from that trigger, not another environment’s URL or secret.
This is a placeholder example, not an instruction to put a real secret in shell history. Configure secrets through your sender’s secure fields. Senders unable to set headers can use ?secret=, but URLs are more likely to leak through logs; prefer the header and rotate a leaked secret. A webhook accepts work before the agent finishes. An accepted response is not a successful investigation. The default cooldown is 60 seconds per trigger; configuration can change it or disable it. It protects against repeated runs, not against an unauthorized sender with the secret.

​
Message templates and incidents

Give each trigger a bounded job, intended runtime, credentials and destination. Webhook payload fields can be referenced with template variables; treat incoming payload text as data, not new permission to do unrelated work. Incident workflows can reuse the open incident conversation rather than starting one per retry. A Watch wires an existing provider alert to a trigger and action. A Watch Group groups 2–50 related members behind one ingress and uses one quota slot. Current trigger limits are 50 per person and 500 per team. For Slack delivery, choose the exact supported channel or DM destination. A complete Watch needs provider-side notification setup, read-back, delivery verification and recorded cleanup. Creating a trigger alone is incomplete.

​
Database alerts

A supported database connection can watch a query and fire when its result crosses a threshold. Configure it from the database’s Monitoring page; validate the query, threshold, cadence and access policy before enabling it.

​
Permissions for unattended work

Automation conversations initially use Full Access. Events in an existing conversation keep its owner’s mode; Auto Mode requests can time out when nobody is present. See Auto Mode and Full Access. Do not assume every automated change waits for a plan. Plan review depends on the entry point and task; a trigger may have no review surface. Restrict provider permissions and selected credentials, and specify investigation-only behavior when that is what you intend. A prompt is not an IAM restriction.

​
Verify, pause and remove

Check the next scheduled run or use a bounded test delivery. Verify the resulting session and intended notification, not merely the API’s acceptance. Prefer disable/pause for temporary suspension. Deleting a Watch can require cleaning up provider-side resources; remove only the wiring recorded as owned by that Watch. Keep a record of any manual cleanup still needed. A shell process, terminal session or background watcher is not a persisted trigger and does not survive every runtime restart. Use a trigger or provider monitor for durable future work.