Automations

Run agents on a schedule or in response to GitHub, GitLab, Slack, Sentry, or custom webhook events.

Automations let you run Replicas agents automatically, on a schedule, in response to GitHub or GitLab events, when messages are posted in Slack channels, or whenever any external system hits a custom webhook URL. Use them for nightly maintenance, scheduled audits, automatic responses to PR activity, reacting to messages in Slack, wiring up a tool we don’t have a first-class integration for, and any other workflow you want to run without a human in the loop.

Automations and the public API are the only sanctioned channels for programmatic use of Replicas. Driving the dashboard, Slack, Linear, GitHub, or CLI from scripts is prohibited under our Terms of Service.

How it works

Each automation has:

• A prompt the agent will receive when the automation runs.
• An environment that supplies the repository (or repository set) plus any vars / files / skills / MCPs layered on top of Global.
• One or more triggers that decide when the automation fires.
• An optional debounce window, in seconds. When set, bursty trigger events update one pending run for the automation; the latest payload runs after the automation stops receiving events for that many seconds.
• Optional coding agent, model, and thinking level overrides. Leave any of them unset to fall back to your organization’s default agent and the agent’s own default model and thinking level.
• Optional plan, goal, and fast mode overrides. Plan mode applies to Claude, Codex, Cursor, and Opencode; goal mode only applies to Codex; fast mode applies to Claude and Codex.
• A workspace size (small or large). Defaults to small (2 vCPU, 8 GB memory, 20 GB disk). Pick large (4 vCPU, 16 GB memory, 32 GB disk) for memory or CPU-bound work; see Billing for per-size rates.

When a trigger fires, Replicas creates a fresh workspace, sends the prompt to the configured coding agent, and tracks the run as an execution you can review in the dashboard.

Personal automations

By default, automations are org-owned and visible to all members. You can also create personal automations that are scoped to your user account:

• Only you can view, edit, trigger, or delete your personal automations
• Workspaces created by personal automations are attributed to you
• Personal automations still count toward your organization’s plan quota (max automations and executions per hour)

Use personal automations when you want workspace runs attributed to you (e.g. personal PR review bots, individual triage workflows) without exposing them to the rest of the org.

Create a personal automation in the dashboard via the Your Automations tab, or via the API by setting scope: "user" in the create request. The CLI supports --personal on replicas automation create. Personal automations require user-level authentication (JWT or personal API key).

List automations by ownership with the scope query parameter:

• scope=org (default) - org-owned automations only
• scope=user - your personal automations only
• scope=all - both org automations and your personal automations

Triggers

Six trigger types are supported today:

Cron triggers

Run an automation on a recurring schedule defined by a standard cron expression. The minimum interval is 60 minutes between runs.

GitHub triggers

Run an automation in response to events from your connected GitHub repositories. You can optionally filter a GitHub trigger to a specific subset of repositories.

Supported events:

• PR opened: fires when a pull request is created
• PR updated (new commits): fires when new commits are pushed to a pull request
• PR merged: fires when a pull request is merged
• PR closed: fires when a pull request is closed or merged (includes merges for backwards compatibility)

GitHub triggers support one optional setting:

• Group PR events: Available on PR opened and PR updated (new commits) only. When enabled, later opened or synchronize events for a PR that already has a workspace from a prior run of the same automation route to that workspace as a follow-up message instead of spawning a new one. Works the same way as Slack’s Group thread replies.

Automation workspaces have no attached user and fall back to the Replicas bot for PR attribution.

GitLab triggers

Run an automation in response to events from your connected GitLab projects. You can optionally filter a GitLab trigger to a specific subset of projects.

Supported events:

• MR opened: fires when a merge request is created
• MR updated (new commits): fires when a merge request is updated
• MR merged: fires when a merge request is merged
• MR closed: fires when a merge request is closed

GitLab triggers support one optional setting:

• Group MR events: Available on MR opened and MR updated (new commits) only. When enabled, later opened or updated events for an MR that already has a workspace from a prior run of the same automation route to that workspace as a follow-up message instead of spawning a new one.

Slack triggers

Run an automation when a new message is posted in a connected Slack workspace. You can optionally filter to specific channels. For example, only fire when someone posts in #nit. Bot messages and message edits are automatically ignored.

Slack triggers support one optional setting:

• Group thread replies (on by default): When a top-level message creates a workspace, subsequent replies in that thread are routed to the same workspace instead of spawning new ones. Turn this off if you want each message to always create its own workspace, regardless of threading.

Slack triggers require your organization to have Slack connected in Organization Settings. The Slack app must be subscribed to message.channels events in the app configuration.

Sentry triggers

Run an automation in response to events from your connected Sentry organization. You can optionally filter to specific Sentry projects, and set a minimum severity level so only events at or above the chosen level fire the automation.

Supported events:

• Issue alert fired (event_alert.triggered): fires when one of your Sentry issue alerts is triggered.
• New issue created (issue.created): fires when Sentry opens a new issue.
• New error event (error.created): fires when a new error event is captured.

Sentry triggers require your organization to have Sentry connected in Organization Settings. See Sentry for how to connect.

Custom webhook triggers

If none of the built-in triggers fit your use case, add a custom webhook trigger. Replicas generates a unique URL for the automation, and anyone with the URL can fire it by sending an HTTP POST with any JSON body:

curl -X POST https://api.tryreplicas.com/v1/automations/webhook/whtok_xxxxxxxx \
  -H "Content-Type: application/json" \
  -d '{"anything": "you want", "nested": {"too": true}}'

The request body is parsed as JSON (non-JSON bodies are wrapped as { "raw": "<body>" }) and embedded into the automation’s prompt under ## Trigger Payload, so your prompt can reference any fields the caller sent.

The endpoint returns 202 Accepted once the execution is queued. It does not wait for the workspace to spin up, so callers stay fast. Disabled automations, unknown tokens, and automations without a custom trigger all return 404 without distinguishing between the three.

The URL itself is the secret. Treat it like an API key: don’t check it into public repos or share it in logs. If the URL leaks, remove the custom trigger and re-add it to rotate the token.

Each trigger event can only be added once per automation. You can still combine distinct events, for example a GitHub pull_request.opened trigger plus a GitLab merge_request.opened trigger, but not two pull_request.opened triggers.

Debouncing

Add a debounce window to any automation to collapse duplicate trigger bursts into one delayed run.

When a matching event arrives, Replicas schedules one pending run for that automation. Additional matching events before the timer expires update the pending run with the latest payload and push the timer out again, so only one run fires after the automation stops receiving events for the configured window. Leave debounce blank or set it to 0 to run every trigger immediately. The maximum window is 24 hours.

Pull request management

Automations are read-only toward matching pull requests by default: they can react to PR events and create a workspace, but they do not register those PRs as Replicas-managed.

Enable Allow PR follow-ups when an automation should run follow-up behavior on matching PRs. This stores config.capabilities.pr_followups: true and snapshots that config onto each run and workspace, so later CI and review-comment replies can route back to the automation workspace.

Automation API clients can set the same behavior through config.capabilities.pr_followups. Replica API clients can also set this workspace capability when creating a replica. Leave it omitted or false for read-only workflows.

Automation config is also copied to each workspace created by the automation, including workspace preferences like config.preferences.keep_open_on_pr_merge.

Plan availability and limits

Automations are available on every plan. Plans differ only in rate limits and the per-cycle pool of included minutes (see Billing).

Plan	Max automations	Org executions / hour	Per-automation executions / hour	Min cron interval
Hobby	2	5	2	60 minutes
Developer	5	20	5	60 minutes
Team	Unlimited	Unlimited	Unlimited	60 minutes
Enterprise	Unlimited	Unlimited	Unlimited	60 minutes

Hobby orgs draw automation runs from a separate 1,200-minute bucket (granted once at signup, not refilled monthly), so they don’t consume the Hobby workspace allotment.

Reliability

Every execution is recorded with its status (pending, creating, running, completed, or failed) and any error message. Automations remain enabled regardless of failures, and continue to fire on their configured triggers until you manually disable them.

Billing

Automation workspaces are metered separately from your seat subscription. Each workspace is billed at the rate of the size it was created with (small or large), so a fleet that mixes both bills at a mixture of the two rates. See Billing for rates, rounding, and plan details.

Personal automation workspaces still use automation metering. They carry the owner’s user_id for auth, credentials, attribution, and security policy checks, but they do not become seat-billed workspaces.

Templates

The automations page surfaces a small set of starter templates with their tags and triggers pre-filled, so you can stand up a useful automation in a few clicks instead of writing a prompt from scratch.

Available templates today:

• Code Review. Posts a single PR comment with an X/5 review score on PR opened and synchronized.
• DRY Code Check. Flags duplicated logic, parallel schemas, and reinvented utilities on PRs.
• No Unused Code. Flags code that became unused as a result of the PR.
• No useEffects Check. Catches unnecessary useEffect escape hatches in React PRs.
• Unnecessary Comments Check. Flags comments that restate code instead of explaining the non-obvious “why”.
• Unnecessary TypeScript Casting. Challenges avoidable as any, non-null assertions, and @ts-ignore escape hatches in TypeScript PRs.
• Documentation Sync. Verifies that docs and the changelog stay in sync with feature changes.

Selecting a template opens a read-only preview. Click Use this template to seed the create form with the template’s name, description, triggers, and prompt. You still pick the environment the automation should run in, which supplies the repository (or repository set) it targets.

Have a suggestion for a new template? Send it to [e-mail].

Managing automations

Automations can be created, updated, listed, and triggered from the dashboard, the CLI, or via the same REST API and API key as the rest of the public API. You can also fire an automation on demand from the dashboard or CLI to test that it works without waiting for the next scheduled or webhook-driven run.

Use the Automations page tabs to switch between organization automations and automations you own in the current organization. In the API, pass scope: "user". In the CLI, replicas automation create --personal creates a personal automation and replicas automation list --owner user lists personal automations.