> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Triggers & schedules

> Run an agent on a recurring cron schedule from the trigger registry — and where inbound webhook endpoints live instead.

A trigger in the Komodor Agentic Operation Platform (KAOP) is a recurring cron schedule that starts
an agent run. That is the whole of it, and the distinction matters: if you want an external system to
start work by posting to a URL, that is an **endpoint**, it lives under Integrations, and it is not a
trigger. This page covers creating and operating schedules, and points you at the right surface for
the inbound case.

<Warning>
  **Triggers are cron schedules.** Inbound webhook endpoints live under **Integrations →
  Endpoints (inbound)**. They are a separate surface with separate authentication, and nothing in the
  trigger registry manages them. See [Inbound endpoints](#inbound-endpoints-are-not-triggers).
</Warning>

## Where triggers live

The trigger registry is account-wide, on the **Triggers** tab of **Fleet**. It lists every schedule
in the workspace rather than only one agent's, which is what makes it useful for answering "what runs
overnight?"

The registry describes itself the same way: *recurring agent runs on a cron schedule*.

## Create a schedule

<Steps>
  <Step title="Open Fleet → Triggers">
    Press **Create schedule**.
  </Step>

  <Step title="Choose the agent">
    One schedule targets one agent. The agent cannot be changed afterwards — to move a schedule, make
    a new one and delete the old.
  </Step>

  <Step title="Write the cron expression">
    A standard five-field expression: minute, hour, day of month, month, day of week.
  </Step>

  <Step title="Set the timezone">
    The zone the schedule's wall-clock time is read in. The dialog defaults to your browser's zone;
    through the API the default is UTC.
  </Step>

  <Step title="Give it input">
    **Input (JSON)** is a JSON object handed to the agent on every fire. Leave it empty and the agent
    runs with no input.
  </Step>

  <Step title="Create it">
    The schedule appears in the registry, enabled.
  </Step>
</Steps>

### Cron expressions

| Expression     | When it runs                          |
| -------------- | ------------------------------------- |
| `0 6 * * *`    | Every day at 06:00                    |
| `*/15 * * * *` | Every fifteen minutes                 |
| `0 9 * * 1`    | Mondays at 09:00                      |
| `0 0 1 * *`    | The first of every month, at midnight |

An expression KAOP cannot schedule is rejected when you save it, with the reason, rather than
failing silently later.

<Note>
  Some cron shapes do not survive a timezone. KAOP runs schedules by converting your local expression
  into its UTC equivalent, so an expression with no single UTC equivalent — a date-specific schedule
  that would shift across a day boundary, for instance — is refused at save time. Write the schedule in
  UTC if you need one of those shapes.
</Note>

### Timezones and daylight saving

Set the timezone to the zone your team thinks in. A schedule written as 09:00 in `Europe/Berlin` is
converted to the equivalent UTC schedule, 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.

### What the run receives

The **Input (JSON)** object is passed to the agent verbatim on every fire. Two shapes are common:

<Tabs>
  <Tab title="A prompt">
    For an agent that takes a natural-language instruction, use the `prompt` key:

    ```json theme={null}
    { "prompt": "Summarize the last 24 hours of production alerts." }
    ```
  </Tab>

  <Tab title="A structured payload">
    For an agent that declares an input schema, supply the fields it expects:

    ```json theme={null}
    {
      "environment": "production",
      "lookback_hours": 24,
      "dry_run": false
    }
    ```
  </Tab>
</Tabs>

A scheduled run is marked as having come from a schedule, and records which trigger fired it, so you
can trace any run back to the schedule responsible.

## Operate a schedule

The registry shows each schedule's **Trigger ID**, its agent, its cron expression, when it **last
fired**, and whether it is **enabled**, alongside counts of how many schedules are enabled and
disabled.

| Action                              | How                                                                   |
| ----------------------------------- | --------------------------------------------------------------------- |
| Disable one schedule                | Turn off its **Enabled** switch. The schedule stays, but stops firing |
| Change the cron, timezone, or input | Edit the schedule                                                     |
| Delete it                           | From the schedule's actions                                           |

### Two independent switches

A schedule fires only when **both** it and its agent are enabled. That gives you two levers with
different reach:

* **Disable the schedule** to stop one recurring job.
* **Disable the agent** to stop *all* of its triggers at once, while leaving manual runs and chat
  working. See [Manage a deployed agent](/manage-your-agents/build/manage-a-deployed-agent).

<Note>
  There is no minimum interval. A schedule can run every minute — which also means nothing stops you
  from scheduling an expensive agent far more often than you meant to. Check
  [Agent spend](/manage-your-agents/optimize/agent-spend-attribution) after adding a frequent schedule.
</Note>

## Schedules an agent declares for itself

An agent can declare its own schedules in its `agent-spec.yaml`, and those register automatically
when the worker connects:

```yaml theme={null}
triggers:
  - id: nightly
    type: schedule
    name: Nightly summary
    cron: "0 6 * * *"
```

These appear in the registry marked **YAML-managed** and are read-only there: the switch and the
delete control are disabled. That is deliberate — the schedule's source of truth is the agent's
repository, so change it there and redeploy. An edit made in the console would be overwritten on the
agent's next heartbeat.

<Tip>
  Declare a schedule in the spec when it is part of what the agent *is* — a nightly digest agent that
  makes no sense without its nightly run. Create it in the registry when it is an operational choice
  you may want to change without a deploy.
</Tip>

The registry also lists the Slack channels an agent subscribes to through its spec, read-only, for
the same reason. Channel routing itself is configured under
[Channels](/manage-your-agents/run/channels).

## Inbound endpoints are not triggers

If something outside KAOP should start a run by making an HTTP request, you want an **endpoint**.
Endpoints live under **Integrations → Endpoints (inbound)** and are a genuinely different object:
they authenticate the sender, they can capture payloads before they route anywhere, and their URL is
stable independently of what they point at.

|                     | **Trigger**                      | **Endpoint**                                   |
| ------------------- | -------------------------------- | ---------------------------------------------- |
| What starts the run | A cron schedule KAOP owns        | An HTTP request an external system makes       |
| Where it is managed | Fleet → Triggers                 | Integrations → Endpoints (inbound)             |
| What you configure  | Cron, timezone, input            | Sender, authentication, field mapping, routing |
| Authentication      | None needed — KAOP is the caller | A token, a signing secret, or a bearer token   |
| Input               | The JSON you set on the schedule | The request body the sender posts              |

Creating one walks through the sender and its name, then **Authentication**, then a **Test & mapping**
step where you can fire a real request and see what arrives, and finally **Routing** — which agent or
workflow it starts.

<Note>
  Routing is the last step and it is optional. An endpoint with no target accepts deliveries and
  captures them without running anything, which is the right way to confirm a sender's payload shape
  before you point it at an agent. You can attach the target later without the URL changing.
</Note>

<Warning>
  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 — set the secret as part of creating it.
</Warning>

For KAOP posting events *out* to a URL of yours, see
[Outbound webhooks](/manage-your-agents/run/outbound-webhooks).

## Everything else that can start a run

Schedules and endpoints are two of several. For the full picture — chat, channels, workflow steps,
modules, agent-to-agent invocation, and manual runs — see
[Run — how it works](/manage-your-agents/run/how-it-works).

## Next steps

<CardGroup cols={2}>
  <Card title="Manage a deployed agent" href="/manage-your-agents/build/manage-a-deployed-agent">
    The agent-level switch that stops every trigger at once.
  </Card>

  <Card title="Runs & evidence" href="/manage-your-agents/run/runs-evidence">
    What a scheduled run leaves behind.
  </Card>

  <Card title="Built-in integrations" href="/manage-your-agents/build/built-in-integrations">
    Where endpoints and outbound webhooks live.
  </Card>

  <Card title="Orchestration" href="/manage-your-agents/run/orchestration">
    Starting several agents in sequence rather than one on a timer.
  </Card>
</CardGroup>


## Related topics

- [How Run works](/manage-your-agents/run/how-it-works.md)
- [AWS Cost Analyzer](/manage-your-agents/build/catalog/aws-cost-analyzer.md)
- [Go SDK](/developer-tools/go-sdk.md)
- [Change Intelligence & Risk Control](/modules-and-workflows/ops-automation/change-intelligence.md)
- [Deploy an agent](/manage-your-agents/build/deploy-an-agent.md)