# Triggers

> Run an agent on a schedule, on a webhook, or on an event in a connected app, and choose where its result goes.

Source: https://docs.runbear.io/triggers

Last updated: 2026-10-07

A deployed agent normally waits to be mentioned. A trigger runs it without anyone
asking: every weekday at 9am, when a webhook arrives, or when something happens in
an app you have connected.

Triggers live on the **Event Triggers** tab of an agent. There are two kinds:

- **Event triggers** run the agent when something happens: an event in an app, or
  a request to a webhook URL.
- **Scheduled jobs** run the agent at set times, on a repeating schedule or once.

## Before you begin

- For app events, the relevant tool connected on the [Tools](/agents/tools/overview.md)
  tab. The trigger picker recommends events from apps the agent already uses.

## Trigger types

Select **Add Event Trigger** and choose when it should run:

| Type               | Kind          | When it fires                                                                                           |
| ------------------ | ------------- | ------------------------------------------------------------------------------------------------------- |
| **On Schedule**    | Scheduled job | On a repeating schedule: every few hours, daily, on chosen days of the week, or on a day of the month   |
| **One-time**       | Scheduled job | Once, at a date and time you pick                                                                       |
| **HTTP / Webhook** | Event trigger | Whenever a request arrives at the trigger's URL                                                         |
| **App event**      | Event trigger | When the chosen event happens in a connected app, such as a new email in Gmail or a new issue in GitHub |

Every trigger carries a prompt, so the same agent can behave differently
depending on what woke it up: a Monday digest, a reply to an incoming ticket, an
alert summary.

## Creating an event trigger

An event trigger is set up in three steps: **When**, **Then**, and **Alert**.

1. **When** — pick **HTTP / Webhook** or an app event, and fill in the event's
   settings, such as which account or repository to watch. To make the agent wait
   before it runs, turn on **Delay before running** and enter a number of minutes,
   from 1 to 1,440 (24 hours); it starts at 5. Waiting helps when the data the
   agent needs, such as a meeting's transcript, is ready only a few minutes after
   the event.
2. **Then** — write what the agent should do with each event. Select **Check and
   Next**, and Runbear lists the tools your instructions mention and flags any the
   agent isn't connected to yet.
3. **Alert** — optionally choose where each run's result is sent. See
   [Where the output goes](#where-the-output-goes).

The trigger starts running as soon as it's created. On its page you can change
its prompt, delay, and alerts, or switch it off. An inactive trigger ignores
incoming events until you switch it back on, and its event settings can't be
edited while it's off.

### Filtering events

> **Note**
>
> **Limited availability.** This feature is being rolled out gradually. Contact [support@runbear.io](mailto:support@runbear.io) to enable it for your organization.

Where it is enabled, event triggers (app events and HTTP / Webhook alike) accept a
**Run only if** condition, so the agent runs only on the events that matter rather
than on every one it receives. The condition is written in plain language and an
AI model judges each event against it; events that don't match are skipped
silently. If the condition can't be evaluated, for example because of an error, the
run goes ahead rather than being dropped.

## Creating a scheduled job

Choose **On Schedule** or **One-time**, then give the job a **Name** and the
**Prompt** the agent receives each time it runs.

- **On Schedule** — under **Repeats**, pick **Hourly** (every 1 to 23 hours, at a
  minute you choose), **Daily**, **Weekly** (on the days you select), or
  **Monthly** (on one day of the month), then a **Time** and a **Timezone**.
- **One-time** — pick the date and time. It starts 15 minutes from now, so you have
  time to finish the form.

Finish with the **Notification** setting (see below) and select **Create
Scheduled Job**. A job's page has a switch to pause and resume it.

## HTTP / Webhook triggers

An HTTP / Webhook trigger gives you a URL of the form
`https://<id>.m.pipedream.net`, shown as **Webhook URL** on the trigger's page.
Send a request to it from any system that can call a webhook.

- **The URL is the only credential.** Requests aren't signed and need no
  authentication, so anyone who has the URL can make the agent run. Keep it
  secret, and delete the trigger and create a new one if it leaks.
- **The call doesn't wait for the agent.** The request is accepted right away
  and the agent runs afterwards, so the caller never receives the agent's reply.
  To get the result, use the trigger's [alerts](#where-the-output-goes) or ask
  for it in the prompt.
- **What the agent receives.** Your trigger prompt, then a short block of
  guidance from Runbear headed "External Trigger Guidance", then the event as
  formatted JSON under the line "External trigger from *app* (*trigger*)
  received with the following data:". The event describes the whole request,
  including its headers and body.
- **Repeated events.** An event identical to one received in the previous 10
  seconds is dropped. Because the event includes details of the request itself,
  two requests with the same body are not necessarily identical events, so don't
  rely on this to absorb your own retries.

## Where the output goes

A triggered run doesn't need a connected channel. Where its result goes is set on
the trigger itself.

- **Event triggers** (HTTP / Webhook and app events) have an optional **How to get
  alerted** step. Turn on any of **Email**, **Slack** (a DM or a channel) and
  **Microsoft Teams** (a chat or a channel), and each successful run sends the
  agent's reply there. Under **Preferences**, **Alert on errors** also sends a
  message when a run fails. With no destination, the run still happens and you
  can review it on the trigger's page.
- **Scheduled jobs** (On Schedule and One-time) have a **Notification** toggle.
  When it is on, you pick a Slack or Microsoft Teams destination and the agent
  posts its reply there each time the job fires. When it is off, the job runs
  silently: the agent still does its work and its tool calls still happen, but
  the reply isn't posted anywhere.

The agent is told not to post to Slack or another messaging app on its own. If
you want it to send a message somewhere as part of the work, say so in the
trigger's prompt. On Claude Agent SDK agents, a file the run produces is uploaded
to the trigger's first Slack destination.

## Scheduled jobs created from chat

People can also ask an agent in chat to do something on a schedule ("every
Monday, summarize last week's tickets"), and the agent creates the scheduled job
itself. Those jobs appear on the **Event Triggers** tab alongside the ones you add
there, and you manage them the same way. Admins can stop agents from creating
them with **Settings → Agents → Scheduling from chat**.

## Limits

By default, an organization can have up to **50 event triggers** and run up to
**1,000 triggered runs per day**. The daily budget is shared by event triggers and
scheduled jobs across the whole organization and resets at midnight UTC. Both
limits can be adjusted for your organization; contact
[support@runbear.io](mailto:support@runbear.io).

The **Event Triggers** tab shows both counts. Its trigger count includes scheduled
jobs as well as event triggers, and the **Add Event Trigger** button is disabled
once that count reaches the limit.

Runs over the daily budget are skipped without notice until the budget resets.
Triggered runs also consume credits like any other message, and they stop when
your organization reaches its credit limit.

## Managing triggers from an AI client

The [Runbear MCP server](/api/mcp-server.md#setting-up-triggers) can create, change,
run, and delete triggers and scheduled jobs from Claude Code, Claude Desktop, or
another MCP client. Until a pending fix ships, it doesn't return an HTTP / Webhook
trigger's URL; copy the **Webhook URL** from the trigger's page.

## Related

- [Tools](/agents/tools/overview.md) — connect the app whose events you want to use
- [MCP server](/api/mcp-server.md) — manage triggers from an AI client
- [Billing and credits](/administration/billing-and-credits.md) — triggered runs consume credits
- [Traces API](/api/traces.md) — inspect what a triggered run did