Automations
An automation is a saved prompt that runs on a schedule. Every run starts a fresh task in each repository the automation covers, so you can open it from run history to review, steer, or continue it with your team, like any other task.
Create an automation
- Open Automations from the sidebar in the web, Mac, or iPad app, or from the Automations button on the iPhone’s Tasks screen, and choose New automation.
- Choose the repositories it runs in. An automation can cover up to 20.
- Choose who it is for in the sharing menu: Only me, one of your teams, or Everyone in your organization. See Sharing.
- Give it a name, or leave the name empty to have one filled in from the first line of the prompt.
- Write the prompt, for example: “Run the test suite, investigate failures or flaky tests, and make focused fixes where the cause is clear.”
- Choose the agent and model (and reasoning effort, where the agent supports it), the worker cluster, and the schedule.
- Choose Create.
Under Or start with, the list offers three starters you can adapt: Dependency check, Test health, and Weekly code review.
Automations need at least one connected repository.
Schedules
| Schedule | Options |
|---|---|
| Hourly | The minute past each hour to run. |
| Daily | The time of day. |
| Weekly | The time of day and any set of days, for example Monday to Friday. |
Each schedule keeps the IANA time zone it was created in, such as America/New_York, so changing devices does not shift it. Daily and weekly schedules follow local wall-clock time through daylight saving changes. A time skipped by a spring-forward change does not run, and a repeated fall-back time runs once.
Editing an automation without changing its schedule keeps the next run in place.
Sharing
| Option | Who can see it | Who can manage it |
|---|---|---|
| Only me (personal, the default) | You | You |
| A team | Members of that team, and owners | Members of that team, and owners |
| Everyone in your organization | Members with access to all of its repositories | Owners |
Only owners can share an automation with the whole organization. A team automation can only use repositories that the team has access to.
Repository access still applies. An automation and its history are visible only to people who can access every repository it selects. The tasks it creates follow the usual repository-based access.
Only the creator can change an existing automation’s sharing. Other managers can edit its prompt, repositories, schedule, and routing.
Who a run acts as
Runs execute as the automation’s creator. Before each run, Rivets checks again that the creator is still a member with access to the repositories. A team automation also requires its creator to still be on the team, and an organization-wide automation requires its creator to still be an owner.
If the creator leaves or is removed from the organization, their personal automations are deleted. For a team or organization-wide automation, if the creator leaves the organization, their account is deactivated, they lose the owner role on an organization-wide automation, or the organization is suspended, Rivets pauses the automation and shows why. Editing it or turning it back on clears the reason. Problems that affect only one repository, such as the creator losing access to it, fail that repository’s run instead.
Routing
Automations route like tasks, as their creator:
- Auto picks an available worker that can run the chosen agent for each run, among the workers the creator may use.
- A cluster pin keeps runs inside that cluster. The pin is strict: if no worker in it is online and able to run, the run fails immediately, with no retry elsewhere. You can only pin a cluster that has a worker shared with both you and the automation’s creator.
An Auto run with no available worker also fails. Reconnect a worker or change the routing, then choose Run now. See Clusters and routing.
Run, pause, and history
- Run now on the automation’s page starts a run immediately, even while the automation is paused.
- The switch on each automation, in the list and on its page, pauses and resumes it. Pausing stops future scheduled runs. Work that has already started keeps going.
- Run history on the automation’s page lists each run for 30 days. Started runs link to their tasks, and skipped or failed runs show why. A run across several repositories is grouped into one row, and runs started with Run now are marked as such. The tasks themselves are not removed after 30 days.
How runs are scheduled
- Server-side. Schedules run on Rivets’ servers, so no app needs to be open. An online worker is still needed to do the work.
- Checked every minute. A run starts shortly after its scheduled time, subject to worker availability.
- No overlap. Only one run of an automation can be active in a repository at a time. If the previous run is still going, the next one is skipped, and history says so.
- No backlog replay. After downtime, missed runs are not replayed one by one. Runs more than ten minutes late are recorded as skipped.
Limits
- Automations run on a schedule only. Triggering them from external events, such as a webhook or a new issue, is not supported yet.
- Each run starts a new task. Reusing a previous run’s task is not supported.