An automation starts work without anyone asking for it each time. It runs on a schedule, or when something happens: a pull request opens, an issue is filed, a check or a deployment fails.
Every automation is listed in the factory under Automations, with what starts it and what it does. Create one in New Work: choose Automation, then choose when it runs.
- ScheduleTime
- Event automationSomething happens
An ordinary task
Specification, plan, build, verify, review. Uses an agent slot; give it a lower priority.
P2P3A pull request
It cannot merge itself or commit to your base branch.
You approve
Two kinds of trigger
| Trigger | Runs | Example |
|---|---|---|
| A schedule | At a set time, at an interval, or once now | Ask Sentry for new errors every hour and open a task for each |
| Something happens | When GitHub or Coroid sends the event | Review every pull request opened on a project |
Use a schedule when the trigger really is time, or when the thing to watch lives in another system that does not send Coroid events, such as Sentry or Jira. The schedule asks that system through your MCP servers and opens work for what it finds. See Schedules.
Use an event when Coroid can be told the moment it happens. It does less pointless work than a schedule that keeps asking.
Events you can choose in New Work
From GitHub, which needs the GitHub App:
- a pull request is opened, updated or merged
- an issue is opened
- a comment mentions Coroid; it counts only when its author has write access to the repository
From Coroid:
- a task, a plan, a Quality check, a deployment or a deployment health check fails
- a release is rolled back
Slack and Telegram messages, new Jira issues, and events your own systems fire need a filter or a service account. Start those from a template in Settings, under Automation, or change an automation's event in its editor. See Hooks.
What it does
When its event fires, an automation does one of three things:
- Review the pull request. Coroid Check reviews it and posts its review on GitHub, with comments on the lines it found and a check run named Coroid Review. Offered for pull requests that are opened or updated.
- Turn it into work. The event is filed as a request. Once Qualification passes it, Coroid creates the task or plan. Offered for issues and for comments that mention Coroid.
- Follow the brief. An agent follows the brief you wrote, with read-only access, and can open tasks. Offered for every event.
None of them changes your code directly. Work an automation opens goes through the same specification, plan, build, verify and review path as anything else, and ends in a pull request you approve.
Review every pull request
To have Coroid review pull requests that people open, not only its own:
- Open New Work and choose Automation.
- Choose the project, or leave it empty to cover every project.
- Under Trigger, choose When something happens. Under Event, choose Pull request opened, and choose Review the pull request.
- Give it a title and a short brief, then continue.
The automation reviews each new pull request, and each update to it, on that project. The repository needs the GitHub App, and the project must not be set to Local only. Pull requests from Coroid's own tasks are not reviewed again: their review is part of the task.
You can also turn on Pull requests for the project in Quality Control. Then the project's checks run on every pull request too, and Coroid Check reviews it as part of the same run.
Watching an automation
Open an automation in the factory to see each run: when it ran, what it cost, what it opened, and why a run did not finish. From there, owners and admins can pause it, test it, edit it or delete it. Everyone in the organization can see automations and their runs.
Keeping automations useful
Work an automation opens competes for the same agent slots as everything else. One that fires often can quietly use up your capacity.
- Give it a lower priority than work people asked for.
P2orP3. - Make the trigger specific. "A check failed" fires constantly on a busy repository. "This check failed on the base branch" fires when something is actually wrong.
- Look at what it produced. If an automation opened twenty tasks and you merged two, it is producing noise and spend, not value.
The honest measure of an automation is how much of the work it opens gets merged, not how often it fires.
Sentinel
Earlier versions of these docs described Sentinel, a monitor that watches for a condition. It is not a separate feature. A condition is either an event, which an automation can run on, or something a schedule checks.