Skip to content
Runbear Docs
GitHub

Triggers

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

On this page
Before you beginTrigger typesCreating an event triggerFiltering eventsCreating a scheduled jobHTTP / Webhook triggersWhere the output goesScheduled jobs created from chatLimitsManaging triggers from an AI clientRelated

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 tab. The trigger picker recommends events from apps the agent already uses.

Trigger types#

Select Add Event Trigger and choose when it should run:

TypeKindWhen it fires
On ScheduleScheduled jobOn a repeating schedule: every few hours, daily, on chosen days of the week, or on a day of the month
One-timeScheduled jobOnce, at a date and time you pick
HTTP / WebhookEvent triggerWhenever a request arrives at the trigger's URL
App eventEvent triggerWhen 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.

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#

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 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.

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 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.