Cursor Automations: Triggers, Templates, and No-Repo Agents

Cursor Automations run work while the editor is closed. They are cloud agents that fire on a schedule or in response to an event, follow the instructions you write, and leave a result where you can inspect it.

Repeated review, triage, and reporting become useful automation targets once you decide the permissions, spending, and failure handling before the first schedule runs.

My own Cursor use centres on cloud agents against deployed development environments, so I judge an automation by the branch, run log, and review path it leaves behind. Pricing and included usage were checked on July 28, 2026.

The Automations Dashboard

The dashboard is a control room rather than an editor view. The top row tracks total automations, successful and failed runs over the last seven days, and a run-history sparkline. Below that sit your own automations and your team's, and under those a marketplace of templates you can add with one click.

Building One, No Repo Required

Creating an automation involves three decisions: when it runs, what it does, and what it can touch. You give it a name, flip it Active, and pick a repository scope.

Alongside a single repository or several, the form offers No Repository. That choice changes the whole character of the automation.

With a repo attached, the agent clones your code into a sandbox and works on an agent branch. Repo-backed runs can push that branch and open a pull request by default. A human still reviews the diff and checks before merge.

A no-repo run never clones code, so it cannot edit code or open a pull request. It can watch connected tools and act on signals, such as reading Slack, a data warehouse, or a billing provider and reporting back.

Set the Operating Boundary

Below the scope you write the agent instructions in plain language, with the same @ for tools and / for commands used in the editor. You choose the model from a curated list and attach tools, including Memories by default and any MCP server you connect.

Once saved, the automation waits for its trigger.

Write the instruction as an operating boundary. Name the event it should handle, the evidence it may use, the destination for the result, and the actions it must avoid. “Summarise new production errors in this channel; do not edit a repository or page anyone” is safer and easier to audit than “handle incidents.”

Triggers

A trigger is what wakes the agent up. The picker covers most of the places work actually originates.

• Scheduled runs on a preset of hourly, daily, or weekly, or on a cron expression you write. Runs can be delayed under load, but they never start before their time.
• GitHub and GitLab fire on the events you would expect: a pull request opened, pushed, labelled, merged, or commented, a push to a branch, or CI finishing. Fork pull requests are not supported except on merge.
• Slack fires on a new message in a public channel, with optional keyword filters, or on a channel being created. Private channels are not visible to the trigger.
• Linear, Sentry, and PagerDuty cover the issue, error, and incident side: a new Linear issue or status change, a Sentry issue event, a PagerDuty incident raised or resolved.
• Webhook gives the automation a private HTTP endpoint. Save it once to generate the URL and an API key, then anything that can POST can start a run, which is the escape hatch for every tool not in the list.

Design for Duplicates and Failures

Events repeat. A pull request can receive several pushes, an issue can change status twice, and a webhook sender can retry after a timeout. Make the first instruction idempotent where possible: ask the automation to update one named comment, label an item only when the label is absent, or report a duplicate instead of opening another ticket.

Also decide where a failed run becomes visible. A weekly report that silently fails is worse than no report because people assume it happened. Send a failure notice to the same channel that receives the successful output, and include the run link or identifier needed to inspect the cause.

What an Automation Can Do Back

The output side is the other half of the story. Beyond editing code and opening pull requests on a repo-attached run, the actions menu lets the agent reach outward.

The native actions cover common handoffs: send a Slack or Teams message, read a channel, and comment on a GitHub pull request, open one, or request reviewers. Everything else rides on MCP, with built-in choices for services such as Linear, Vercel, Cloudflare, Convex, and Clerk.

Memories can carry context between runs. Repo-backed runs work on agent branches and can push or open pull requests by default, so branch protection and human review remain the merge boundary.

Templates

The marketplace ships ready-made automations grouped by job. Dashboard categories cover code review, security, incident triage, and data research. Named starters include finding critical bugs, scanning for vulnerabilities, generating docs, and adding test coverage.

The no-repo additions from May include a Slack digest that summarises morning messages by priority and an analytics agent that pulls weekly metrics. Add one, read its instructions, and tune it to your stack before enabling it.

Automated Code Review

The review and security templates are a practical place to start because the event, output, and reviewer are clear. A pull-request trigger can leave a non-blocking comment before anyone decides whether the findings are useful enough to become a team gate.

What It Costs

Automations run as cloud agents, and cloud-agent usage can be metered differently from ordinary editor work. Treat every recurring trigger as a budgeted system. Cursor’s current pricing page lists included usage and on-demand billing terms; the rate can differ by plan, model, and workspace settings.

Set a spending limit before enabling cloud agents and inspect the Automations documentation before scaling a schedule. Billing ownership, token rates, trial discounts, and included usage can change; date any internal budget decision to the plan page you checked.

Limits and Gotchas

• Max Mode is forced, so cost is the first thing to control. Set a cap and watch the first week.
• Scheduled runs can lag under load. They will not run early, but do not build a hard real-time dependency on the second.
• Fork pull requests are unsupported except on merge, and only public Slack channels are visible to Slack triggers.
• No-repo automations cannot touch code. That is the point, but it surprises people who expected a monitor to also open a fix.
• Repo runs use agent branches. They can push and open pull requests by default; branch protection and human review still decide what merges.

Keep the first production version deliberately dull. One trigger, one source, one destination, one owner, and one written stop condition are enough. Add MCP connections, external writes, and parallel schedules only after the simple run has produced reliable evidence for several cycles.

FAQ

What do Automations cost?

They consume cloud-agent usage. The exact rate, included amount, and overage policy can change, so check Cursor’s current pricing page before you turn on a recurring trigger. Set a limit first, then measure a bounded trial before relying on an automation every day.

Do I need a repo?

No. A no-repo automation can monitor events and report back, but it cannot clone code, make edits, or open a pull request. Use it for a digest, alert, or research task when a report is useful but a repository write would be unsafe or unnecessary.

Can they review PRs?

Yes. A pull-request trigger can run review instructions and leave results through the configured GitHub actions. Start with one repository and a non-blocking comment workflow, then inspect false positives, missed issues, run cost, and permissions before treating the output as a required gate.

How should I test an automation?

Start with a manual trigger or a narrow event on a disposable branch. Give it read-only instructions or a reporting task, check the run log and output location, then add a single write action if the result is reliable. Test failure, duplicate-event, and permission paths before scheduling it.

Related

• Cursor guide for the editor and pricing it all sits on.
• Best AI code review tools for BugBot and the wider review landscape.
• Cursor vs OpenCode for how the cloud-agent and automation story compares with the open-source side.

When Automation Earns Trust

Cursor Automations are most valuable for small, repeatable jobs with a visible owner and output: a pull-request check, scheduled report, incident summary, or issue triage step. Begin with reporting and strict limits, then earn additional permissions through observed runs. Keep human review responsible for the merge while the automation reduces a specific queue of work.