Skip to main content
A trigger is anything configured on an agent that starts a run. In the Komodor Agentic Operation Platform (KAOP) triggers belong to the agent and are added on its own page, so the answer to “what can start this agent?” is one list rather than several registries you have to cross-reference. The Triggers tab is the complete list of what starts the agent on its own. Manual invocation — Run agent and a direct API call — is separate, and keeps working when the agent is disabled; see The agent page.

The four kinds

An agent commonly has several at once — a schedule for the routine pass, a webhook for the urgent one, chat for a person who wants to ask directly. They are independent of each other, and disabling the agent stops all of them.

Schedules

A schedule is a standard five-field cron expression plus a timezone, and optionally a JSON input handed to the agent on every fire. Set the timezone to the zone your team thinks in. A schedule written as 09:00 in Berlin is converted to its UTC equivalent, and that conversion is re-derived as the offset changes — so the run stays at 09:00 local across a daylight-saving transition rather than drifting by an hour twice a year. An expression KAOP cannot schedule is rejected when you save it, with the reason.
There is no minimum interval. A schedule can run every minute, which also means nothing stops you scheduling an expensive agent far more often than you meant to. Check the agent’s budget after adding a frequent schedule.

Schedules an agent declares for itself

An agent can declare its own schedules in its spec, and those register when the worker connects:
They appear badged Declared in agent-spec and are read-only in the console, because the schedule’s source of truth is the agent’s repository — an edit made here would be overwritten on the agent’s next contact. A spec-declared schedule with no timezone runs in UTC. Declare a schedule in the spec when it is part of what the agent is: a nightly digest agent makes no sense without its nightly run. Add it on the agent when it is an operational choice you may want to change without a deploy.

Endpoints are not triggers

A webhook trigger belongs to one agent and starts it directly. An inbound endpoint is a different object, living under Connections: it authenticates a specific sender, it can capture payloads before routing anywhere, and its URL is stable independently of what it points at. An endpoint with no target is a legitimate state: it accepts deliveries and captures them without running anything, which is the right way to confirm a sender’s payload shape before pointing it at an agent. The target can be attached later without the URL changing.
An endpoint’s token is shown once, when it is created or rotated. A GitHub endpoint validates every delivery against a signing secret, so an endpoint created without one rejects everything while looking configured.

Next steps

Connections

Where inbound endpoints and outbound webhooks live.

The agent page

Where an agent’s triggers are added and read.