Cursor Rollouts: PR Health Through Production

Rollouts attaches to a pull request while it is still in review and stays attached until the change is verified in production. Its first move is to read the diff and the systems the diff touches, then write a rollout plan. You configure it in Automations, and it is available on Teams and Enterprise plans.

The last row is gaps in instrumentation: anything that would make the change hard to verify.

On GitHub, GitLab.com and Bitbucket Cloud, Rollouts posts the plan as a comment on the pull request. On Origin, the plan appears on the pull request page. To change it, mention the handle the Rollouts comment names and say what to watch or ignore, and Rollouts revises the plan and replies. Only people with write access to the repository can change the plan.

Rollouts runs the plan against your logs, metrics and traces after the change deploys.

Rollouts wakes on deploy events for the change's commit and runs the plan against your logs, metrics and traces. It tracks each environment separately, so a change can be verified in staging and still flagged in production.

The docs do not say why the schedule is shaped this way.

Each environment a change deploys to shows its own status, such as Deploying, Monitoring, Verified, Deploy failed or Issues found. A green staging run therefore cannot hide a red production one, because the two are tracked and reported separately.

Tracking depends on a deployment being recorded. If a merged change goes live without one, select Run checks on the change's page. The button sits to the right of the environment tabs, and on its own in that row before the change has checks. Choose the environment and services, then start the checks. Rollouts treats the change's version as live in that environment and checks it on the same schedule.

When Rollouts detects a regression, it names the change it suspects, opens an issue and notifies the author. It does the same when a change causes no regression but does not work as intended: the new code path ran, but its effect is missing, it errors, or its behavior is wrong.

That second trigger covers a change that does nothing, not only one that makes something worse.

Because the close reason and the note both stay on the history, a closed issue carries its own explanation for whoever opens it next.

Where do changes show up?

The Rollouts page lists merged pull requests and groups them into Attention, Monitoring, Pending and Verified. Mine lists the changes you are subscribed to, and Team lists every change on the team. Team admins land on Team, and everyone else lands on Mine.

Those are the statuses an environment can show. A change sits in Attention while it has an open issue or a failed deploy, and once every issue on the change is closed it counts as Verified. Reopening an issue moves it back to Attention, so Verified is a state a change can lose, not a stamp it earns once.

Select Services at the top of the page to see each service your deployment pipeline reports. To hide one from that list, open it and select Archive. Its deployments stay in history, and the service moves under Archived, where Restore brings it back.

In Automations, open the Team tab and select Enable on the Rollouts card under From Cursor. Setup then has four steps.

1. 1Access to monitored repositories: choose the repositories to watch. Every pull request that ships from them gets its own watch, tied to its author. Origin, GitHub, GitLab.com and Bitbucket Cloud are supported.
2. 2Send deployment events: create an API key and store it as the CURSOR_API_KEY CI secret, then add the calls manually or let a setup agent open a pull request that adds them.
3. 3Telemetry: connect your observability tools, such as Datadog.
4. 4Notifications: choose how pull request authors get notified about their rollouts.

Rollouts needs at least one connected telemetry tool. Without one, changes stay pending and Rollouts can't detect issues.

The key can be a user API key, a service account API key, or a team Admin API key with the admin:* scope. With the agent route, you merge the pull request it opens to finish setup.

Rollouts relies on your pipeline to report deploys. Four kinds of call carry that: one at the top of the deploy job, a one-time pair that creates the environment and service, one right before you ship, and one right after the outcome is known.

deployVersion is the commit SHA being shipped. Rollouts wakes on deploy events for the change's commit, so the SHA you report is what ties a deploy to the change it belongs to.

The docs add one rule: a failed report must never fail the deploy. The reporting calls are bookkeeping, and a deploy that is otherwise fine should not stop because of them.

Settings has four sections, and the switch at the top reads Enabled or Disabled. Only team admins can turn Rollouts on or off or set up deployment events. Other members see those controls but cannot change them.

Under Which changes to monitor, you describe in plain English the pull requests Rollouts should skip. By default it skips changes that cannot affect what runs in a deployed environment: documentation-only changes, formatting, lint or typo fixes with no behavior change, and test-only changes. Clear the text to monitor every change in the watched repositories.

A pull request is skipped only when it clearly matches. When Rollouts skips one, it says why in a comment. To monitor it anyway, mention the handle the comment names.

Turn on Personal Slack Notifications to hear about your changes in Slack. It starts with Issues found messages only. To also hear when a deployment succeeds or fails, or when a check finds no issues, turn on Deployment succeeded, Deployment failed or Check clear. Under Deliver to, choose Direct message or Channel. For a channel, enter a public channel name or its ID, invite each app named under the field, then save.

Team defaults work on top of that. Only team admins can change them, and turning on the team default sends members a Slack message when a check finds issues with their pull request, until they change their own settings. Enabling Rollouts switches Slack notifications for the team on for Issues found messages, unless the team already has notification defaults.