pages/cloud-agent/automations.txt

route: /docs/cloud-agent/automations
title: Automations
description: Run cloud agents automatically on a schedule or in response to events.

Automations
Cursor Automations run cloud agents in the background, either on a schedule or in response to events from GitHub, GitLab, Slack, webhooks, Linear, and more.
Automations can be used to automate tasks like reviewing recent PR commits for bugs, performing deep review for vulnerabilities, triaging bugs in Slack, and summarizing changes to your codebase on a schedule.
Getting started
Create a new automation in the Agents Window, at cursor.com/automations, with the /automate skill from a local agent session, or from a template in the Cursor Marketplace.
The /automate skill lets you describe the workflow you want in plain language. Cursor configures the automation's triggers, instructions, and tools for you.
For any path:
Choose a trigger, e.g. every hour or when a pull request is opened.
Write a prompt with instructions for the automation.
Choose optional tools the agent is able to use, such as Send to Slack, Comment on Pull Request, or tools from MCP.
Choose whether the automation needs a repository, multiple repositories, or no repository at all.
Save and activate the automation.
Billing
Automations create cloud agents and are billed based on cloud agent usage. See cloud agent pricing for details.
Automations always run in Max Mode because they run as cloud agents. There is no toggle to turn Max Mode off.
How usage is billed depends on the automation's permission scope:
Team Owned: Usage is billed to the team's usage pool. Automations execute under a shared team service account, so no individual user's usage is affected.
Private: Usage is billed to the user who created the automation.
Team Visible: Usage is billed to the user who created the automation, the same as Private.
Triggers
Triggers decide when an automation runs. An automation can have more than one trigger and is run when any trigger fires.
For certain triggers like Slack or cron schedules, Cursor defaults to not using a repository. If your automation should make code changes, specify which repository or repositories agents should work in. For GitHub and GitLab triggers, specifying a repo or multiple repos is required.
Scheduled triggers
Scheduled triggers run on a recurring schedule. Choose from preset options or enter a cron expression for precise control.
Scheduled triggers may run with a delay but will not start before the indicated time.
GitHub and GitLab triggers
GitHub and GitLab triggers respond to pull request events, such as when a pull request is opened or merged. You can connect the automation to one repository or a multi-repo environment.
Draft opened - When a draft pull request is created.
Pull request opened - When a non-draft PR is created or a draft is marked ready for review.
Pull request pushed - When new commits are pushed to an existing PR.
Pull request label changed - When a specific label, or any label, is added to or removed from an existing PR.
Pull request merged - When a PR is merged.
Pull request commented - When someone comments on a PR.
Push to branch - When commits are pushed to a specific branch outside a pull request.
CI completed - When a GitHub or GitLab check finishes on a pull request or branch.
Automations can also be triggered from the following GitHub issue, review, and workflow events:
Issue comment - When a comment is made on a non-PR issue.
PR review comment - When an inline comment is left on a pull request diff.
PR review submitted - When a PR review is submitted.
Review thread updated - When a review thread on a pull request is marked resolved or unresolved.
Workflow run completed - When a GitHub Actions workflow run finishes on a pull request or branch.
The Cursor Marketplace includes templates for triaging failed GitHub Actions and fixing pull request review comments.
Pull request triggers don't run on PRs opened from forks. These runs fail with a "Fork pull requests not supported" error because the branch only exists on the fork, and running external code with the repo's permissions isn't safe. The exception is Pull request merged triggers, which still run because they start from the merge commit. To work around this, push the branch to the repo itself and open the PR from there.
Slack triggers
Slack triggers respond to events from the Cursor Slack integration.
Only public Slack channels are visible to Slack triggers at this time.
New message in channel - When a message is sent to a connected Slack channel. Without a message filter, the trigger only fires on top-level channel messages. Add a keyword or regex filter if you want runs from threaded replies as well.
Emoji reaction - When someone reacts to a Slack message with a specific emoji.
Channel created - When a new public Slack channel is created in your workspace.
Webhook triggers
Webhook triggers create a private HTTP endpoint for your automation. POST to the endpoint to start a run. You can use webhooks to connect automations to internal systems, CI pipelines, monitoring tools, and more.
To retrieve the webhook URL, you must save the automation first, which will then generate a webhook URL to call and an API key for authentication.
Linear triggers
Linear triggers respond to events from the Cursor Linear integration.
Issue created - When a new issue is created.
Status changed - When an issue's status changes.
End of cycle - When a Linear cycle completes.
Sentry triggers
Sentry triggers run when error and issue events occur in your Sentry project. Use them to automatically investigate errors, identify root causes, and propose fixes. See the Investigate Sentry issues marketplace template for a ready-made example.
Issue created - When a new issue is created in Sentry.
Issue updated - When an existing issue changes, such as a status or assignment update.
Any issue event - Matches all issue event types.
PagerDuty triggers
PagerDuty triggers run on incident events and can be helpful to automatically triage or even resolve incidents.
Incident triggered - When a new incident is created.
Incident acknowledged - When an incident is acknowledged.
Incident resolved - When an incident is resolved.
Any incident event - Matches all incident event types.
Tools
Cursor Automations can have tools enabled for richer capabilities around GitHub, Slack, memory, MCP, and more. Automations also include the same base set of tools as other cloud agents. See Cloud agent capabilities for details.
Pull request creation
Repo-backed automations can open pull requests after making code changes requested by the automation prompt. This tool is enabled by default for every automation.
The pull request is opened against the repositories specified for the GitHub or GitLab trigger. For other triggers, it uses the repositories specified by the environment.
Comment on pull request
Posts comments on a target pull request. Supports top-level review comments and inline code comments.
If you enable approvals, the agent can also approve, request changes, and dismiss reviews. Otherwise, it can only post comments.
Request reviewers
Requests reviewers on a target pull request. The agent can use git, memory, and other tools to identify domain experts.
Send to Slack
Sends messages to a Slack channel. You can target a specific channel or let the agent dynamically choose any channel.
When you allow any channel, Cursor also includes the read access needed for the agent to discover available public channels.
Note that the agent is granted read access to public channels that it can send messages to.
Read Slack channels
Gives the agent read-only access to list and read messages from public Slack channels.
Use this when the agent needs more context before it replies or opens a pull request.
MCP server
Connects an MCP (Model Context Protocol) server so the agent can use external tools and data sources.
Connecting an MCP server gives the agent access to every tool exposed by that server. Only conn
…