Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.replicas.dev/llms.txt

Use this file to discover all available pages before exploring further.

Automations let you run Replicas agents automatically, on a schedule, in response to GitHub 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.
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.

​
Triggers

Five 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 closed: fires when a pull request is closed or merged
GitHub triggers support two optional settings:
  • Attach to user: Resolves the GitHub user who triggered the event to a Replicas user in your organization and attaches them to the created workspace. This enables security policy enforcement for automation-created workspaces, ensuring that the same policies that apply to a user’s manual workspaces also apply when an automation runs on their behalf.
  • 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.

​
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 two optional settings:
  • Attach to user: Resolves the Slack user who posted the message (via their email) to a Replicas user in your organization, enabling security policy enforcement on the workspace. Works the same way as the GitHub trigger equivalent.
  • 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 pull_request.synchronize trigger, but not two pull_request.opened triggers.

​
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).
PlanMax automationsOrg executions / hourPer-automation executions / hourMin cron interval
Hobby25260 minutes
Developer520560 minutes
TeamUnlimitedUnlimitedUnlimited60 minutes
EnterpriseUnlimitedUnlimitedUnlimited60 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

Automations include a circuit breaker: if an automation fails 5 times in a row, it is automatically disabled to prevent runaway behavior. You can re-enable it from the dashboard once the underlying issue is fixed. Every execution is recorded with its status (pending, creating, running, completed, or failed) and any error message.

​
Billing

Automation workspaces are metered separately from your seat subscription, at the same rate as API usage. See Billing for rates, rounding, and plan details.

​
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 useEffects Check. Catches unnecessary useEffect escape hatches in React 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 founders@replicas.dev.

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