Triggers

A trigger starts a job when something happens in a connected service: an email arrives, an issue is opened, a file lands in a folder. Where a schedule runs a job at a fixed time, a trigger runs it in response to an event.

Set up per job

Triggers are configured per job, either on the job’s Triggers tab or by asking your main agent. A job can have several triggers, and it can have triggers and a schedule at the same time. Each distinct event type can be used once per job.

The connector has to be connected first. You pick the connector, then the event, then fill in whatever that event needs, such as a label to watch or a channel to listen to.

Not every connector offers triggers, and the events differ by service. You can browse what each one has in the integrations directory, or ask your main agent, which can list a connector’s triggers and read the configuration each one takes.

The event data reaches your prompt

When an event starts a run, the event payload is appended to your prompt:

<your job prompt>

This run was started by a "GMAIL_NEW_GMAIL_MESSAGE" event from the gmail connector.
--- TRIGGER EVENT DATA ---
{ ...the event payload... }
--- END TRIGGER EVENT DATA ---

So write the prompt as instructions for handling one event. “Read the email in the trigger event data and draft a reply” works better than “Check my inbox for new email.” The agent already has the event and does not need to go looking for it.

Large payloads are capped. Anything over the cap is truncated, and the full payload is written to a file in the run’s working directory, so the agent can still read all of it if it needs to.

How fast events arrive

Golemry receives events as signed webhooks, but the connector platform reaches many services by polling them. For a polled event, delivery can take up to about 15 minutes. Some triggers expose an interval setting; lowering it below the polling floor does not make events arrive any faster.

Treat triggers as “shortly after the event”, not “instantly”.

One event, one run

Each event starts one run. Events are deduplicated, so a redelivered event never runs your job twice.

There is no batching and no queueing. Ten events in a minute start ten runs, and a new event starts a run alongside one that is already going rather than waiting for it to finish.

If you have used up your monthly allowance, an arriving event is dropped rather than held. It does not run later.

Pausing and health

A trigger is either Active or Paused. Pausing stops it at the connector, and any event that still arrives is discarded.

Two health states can appear next to a trigger:

• Disconnected: the connector no longer has an active connection, so the trigger cannot fire. Reconnect the connector.
• Out of sync: Golemry and the connector platform disagree about the trigger. This usually means the trigger was disabled on the connector side, for example after credentials expired. Remove the trigger and add it again.

Disconnecting a connector removes its triggers from every job that used it. Deleting a job removes its triggers too.