Automation use cases

​

Before you start

1. Set the Base Scope. In the CodeRabbit web app, open Slack > Scopes and make sure the Base Scope includes the repositories the agent should read. Automations run with the same repository and tool access as a normal request in that channel. See Scopes.
2. Connect your tools. Go to Connections > Add connection. Each guide below lists the connections it needs. Only global admins and scope admins can add connections, and a saved connection isn’t used until it’s added to the Slack Base Scope or to a named scope. See Connections.
3. Add the bot to private channels. CodeRabbit joins public channels automatically. For a private channel, run /invite @coderabbit in the channel first. Otherwise, saving the automation fails with “CodeRabbit could not post in that Slack channel.”
4. Check who can create automations. In Account Settings, the automation creation setting can be Any user (the default), Slack admins or above, or Automation admins or above. If people see a message that only admins can create automations in this workspace, an admin needs to change this setting or create the automation for them.
5. Set a budget. Automation runs use Agent minutes, the same as manual requests. In Slack > Scopes, each scope has an Automation spend limit that is separate from its User spend limit. For channels where every message can start a run, such as the question and support automations, add a named scope for that channel with its own automation limit.

​

Three ways to create an automation

​

Test before you trust it

• Created in Slack chat: the agent runs the job once before you save. Change the wording and run it again until the output looks right.
• Schedule: turn it on and use Run now to see the output right away. Run now isn’t available while the automation is paused.
• Slack channel message trigger: Run now isn’t available. Turn the automation on, then post a real message that matches, or start in a test channel. A paused automation ignores new messages.
• Webhook: turn the automation on, then send a test event from the other tool. For example, PagerDuty sends pagey.ping. The automation’s run history shows whether each event matched, and whether it ran or was skipped as a duplicate.

​

Respond to an incident

​

Option A: watch the channel your alerts already post to

1. In that channel, ask:
   Slack message

   @coderabbit Watch this channel. For every new Datadog alert that says "Triggered", investigate it and reply in the alert's thread using the steps below.
   
2. Paste the starter instructions into the same message, send it, review the sample run, and select Create automation.
3. To cut noise further, limit the trigger to the alerting bot and to phrases such as Triggered, P1, or [Prod].

​

Option B: send alerts from the source with a webhook

1. In the web app, open Automations, choose a Webhook trigger, and pick PagerDuty, Datadog, Sentry, or Google Cloud. For PagerDuty, a global admin connects PagerDuty once and CodeRabbit manages the webhook subscription for the whole account. The Triage PagerDuty incident and Add assessment to PagerDuty incident templates are a good start.
2. Choose event types, such as incident.triggered, and add filters such as event.data.priority.name equals P1. Datadog starts with a filter on alert_transition equals Triggered.
3. Choose the destination Slack channel.
4. Save and turn the automation on. For PagerDuty, CodeRabbit sets up the webhook for you. For Datadog, Sentry, or Google Cloud, follow the setup steps shown to add the webhook in that tool. Then send a test event.

​

Incident starter instructions

When a new alert arrives:
1. Verdict first: is it Real, Likely noise or Unclear? Check whether the monitor is still breaching and whether it has flapped in the last 24 hours. If it's noise, say why in one line and stop.
2. What changed: list the PRs merged and deploys to the affected service in the last 48 hours, each with its author, reviewer and a one-line summary. Put the most likely cause first.
3. Likely owners: the authors and reviewers of the most relevant PRs, plus the service owner if the knowledge base has one.
4. Next step: roll back, revert a specific PR, or look at a specific dependency.
Keep the reply under 15 lines. Don't change code, and don't acknowledge, resolve or reassign the incident unless someone in this thread asks.

​

Make incident response more useful

• Teach it your runbooks. Run /learn or ask “@coderabbit remember that the payments service is owned by #team-payments and rollbacks go through Argo.” Facts saved in public channels are shared across the workspace. You can also ask the agent to turn a good investigation into a skill, so every alert gets the same checklist.
• Keep working in the thread. In automations created from Slack chat, the agent can also respond to later replies in the alert thread. For example: “if someone says fix it, open a revert PR.”
• Add one-click buttons. End the instructions with “Add buttons: Open revert PR (open a PR reverting the most likely cause), Draft RCA (write an RCA in this thread) and Mark as noise (save to the knowledge base that this alert was noise).”
• Escalate the serious ones. Add to the instructions: “If your verdict is Real and the priority is P1, also post a 3-line summary to #incidents with a link to this thread.”
• Record the assessment in your incident tool. Add a PagerDuty connection as a destination, or use the Create Jira issue from PagerDuty incident, Create Linear issue from PagerDuty incident, or Create GitHub issue from PagerDuty incident templates to file follow-up work.
• Schedule the RCA. In the incident thread, ask: “@coderabbit tomorrow at 10am, draft an RCA for this incident in this thread.” That sets up a one-time automation.
• Require sign-off before risky actions. Give people the Approver role in the channel’s in Slack > Scopes. When an action needs approval, the run pauses until an Approver approves or rejects it in Slack. Automation runs are covered too: the requester is the automation’s creator, or whoever selected Run now. Each Approver needs their GitHub account linked to their Slack account, or the scope won’t save.

​

Answer code and product questions

​

Option A: mention the agent

​

Option B: answer every question in the channel

1. Create the channel, for example #ask-eng.
2. Recommended: in Slack > Scopes, add a named scope for this channel. Give it only the repositories and connections it needs, and set its own Automation spend limit, because every post can start a run.
3. In the channel, ask:
   Slack message

   @coderabbit Answer every new question posted in this channel, replying in its thread, using the guidelines below.
   
4. Paste the starter instructions into the same message, send it, review the sample run, and select Create automation.

​

Question starter instructions

Most people asking here work in support, sales or product and can't see the code.
- If the message isn't a question about our product or code (for example an announcement or a thank-you), or an engineer has already answered, don't reply.
- Answer in plain language first, in 3–6 sentences. Then add an "Evidence" line with the relevant files or PRs.
- If the behavior changed recently, link the PR and the release it shipped in.
- Say how confident you are. If you're not sure, say so and suggest who would know (the recent authors of that code) without @-mentioning them.
- Don't paste more than 10 lines of code.

​

Make answers more useful

• Learn from engineer corrections. When an engineer corrects an answer, reply with “@coderabbit remember this” or use /learn. Over time, the agent answers what used to need an engineer. See Knowledge Base.
• Connect your docs and trackers. With Notion, Google Drive, Linear, or Jira connected, the agent can say “this is a known issue, tracked in ENG-1234, fix planned for the next release” instead of only describing the code. Tools without a built-in connector can be added as MCP servers.
• Add a weekly FAQ digest. Add a second, weekly automation in the same channel: “Every Friday at 3pm, summarize the questions asked this week, group repeats, and flag the ones we answered with low confidence.” This shows what to document.
• Add follow-up buttons. End the instructions with “Add buttons: Explain more simply (rewrite the answer for a non-technical reader), Save to knowledge base (save this answer as a fact) and Find an owner (name who most recently changed this code).”

​

Triage incoming support tickets

​

Option A: trigger on every new ticket

1. In the web app, open Automations, choose a Webhook trigger, and pick Zendesk, Intercom, or Pylon.
2. Choose the events, for example ticket.created for Zendesk or conversation.user.created for Intercom. For Pylon, create a Pylon trigger with the send webhook action. The editor walks you through it.
3. Optional: add a filter so only some tickets run, such as detail.priority equals HIGH for Zendesk or issue.priority equals urgent for Pylon.
4. Choose the destination Slack channel, for example #support-escalations. Add your support tool as an additional destination if the agent should write an internal note on the ticket.
5. Save and turn the automation on, set up the webhook in your support tool by following the steps shown, and send a test ticket.

​

Option B: trigger on escalations posted in Slack

​

Support starter instructions

A new support ticket has arrived. Using the ticket, our repositories and the knowledge base:
1. Classify it as Bug, Expected behavior, Known issue or Needs more info, and explain why in two sentences, citing code or PRs.
2. Rate severity (Critical, High, Normal or Low) and say who is affected. If Salesforce or HubSpot is connected, include the customer's plan.
3. Link related PRs, the release that shipped a fix (if any), and any open Linear or Jira issue for the same problem.
4. Draft a reply to the customer in a friendly, concise support tone. Don't send it.
Post the summary in this channel with the draft reply in a quote block.

​

Make support triage more useful

• Keep a person in the loop before anything is sent. The starter instructions say “Don’t send it,” so the automation only drafts. Add buttons that do the sending: “Add buttons: Post as internal note (add the draft to the ticket as an internal note), Send reply to customer (post the draft as a public reply), File Linear bug (create a Linear issue with the analysis).” Nothing reaches the customer until someone selects a button. Start with internal notes until you trust the drafts.
• Feed it your known issues and macros. Use /learn for workarounds and known issues, and ask the agent to save your triage steps as a skill so every ticket gets the same checks.
• Rank severity by customer. Connect Salesforce or HubSpot so the agent can weigh severity by the customer’s plan or deal size.
• Tie into incident response. Add to the instructions: “If severity is Critical, also post a summary to #incidents.” If the incident automation watches #incidents, one flow feeds the other.
• Add a weekly themes report. “Every Monday, summarize last week’s tickets in this channel by root cause, and list the top 3 code areas generating tickets.” Engineering managers can use it in planning.

​

Triage new engineering tickets

​

Option A: triage each new ticket

1. In the web app, open Automations and start from the Triage Linear issue, Triage Jira issue, or Triage GitHub issue template. Use Recommend fix on Linear issue or Recommend fix on Jira issue if you also want a proposed fix.
2. Configure the trigger:
   • Linear: choose or connect a Linear workspace (CodeRabbit manages the webhook for you), pick the teams, and choose events such as Issue.create.
   • Jira: connect Jira (CodeRabbit manages the webhook) and pick up to 50 projects.
   • GitHub: pick a repository the CodeRabbit GitHub App already has access to and choose the issues event. No personal token is needed.
3. To triage only some tickets, add a filter, for example only issues with the label needs-triage, or only issues in a Triage status.
4. Add destinations: the tracker connection to post the comment, and a Slack channel for the summary.
5. Save, turn the automation on, and create a test issue.

​

Option B: daily backlog sweep

@coderabbit Every weekday at 8am, review Linear issues in the ENG team that are in Triage and don't have a CodeRabbit triage comment yet. Triage each one using the steps below, then post one summary here listing what you triaged.

​

Engineering ticket starter instructions

Triage this issue:
- Affected area: the services, directories and files most likely involved.
- Likely owner: who has merged or reviewed the most PRs in that area in the last 90 days.
- Related work: open or recently merged PRs, and possible duplicate issues.
- Effort and risk: S, M or L, with one sentence on what makes it risky.
- Suggested priority and assignee, with reasons.
- A plan in 3–6 steps.
Add this as a comment on the issue. Don't change the assignee, priority or status yourself. Post a 3-line summary in this channel with a link to the issue.

​

Make ticket triage more useful

• Turn the plan into code. End the instructions with “Add buttons: Assign to suggested owner (assign the issue to the owner you suggested), Write full plan (create a Coding Plan for this issue) and Open a PR (implement the plan and open a PR).” turn the short plan into a full implementation plan, and CodeRabbit can implement it and open the PR. A GitHub repository can be an automation destination, so the PR is opened with the CodeRabbit GitHub App’s permissions.
• Keep code work out of the triage channel. If Code Channels are enabled, implementation moves to its own channel, and the triage channel only sees the summary.
• Use Issue Enrichment for GitHub issues. Issue Enrichment comments on new GitHub issues automatically with duplicates, related PRs, suggested assignees, and labels. Use the automation for Linear and Jira, or when you want the Slack summary and buttons.
• Teach it who owns what. Use /learn for team ownership and service boundaries that aren’t clear from the code, such as “billing UI is owned by the Growth team even though Platform wrote it.”
• Follow the PRs to merge. Once PRs are open, Triage in Slack keeps them moving with digests, reviewer requests, and reminders.

​

Tell customer-facing teams what changed

​

Set up a weekly summary

1. In the channel where the summary should go, for example #customer-updates, ask:
   @coderabbit Every Monday at 9am, summarize the customer-visible changes merged to our product repositories in the last 7 days, using the guidelines below.
   
2. Paste the starter instructions into the same message, send it, review the sample run, and select Create automation.
3. If customers only see some of your repositories, name them in the request, for example “in the web-app and api repositories.”

​

Change summary starter instructions

Summarize what changed for customers in the last 7 days:
- Include only changes a customer could notice: new features, behavior changes, fixes for bugs customers could hit, removed or deprecated features, and changes to limits or permissions. Skip refactors, tests, internal tools and dependency updates.
- For each change, write a plain-language headline, who it affects (everyone, admins, a plan or an integration) and one sentence Support can use to explain it. Link the PR.
- Group the changes under New, Changed, Fixed and Heads-up (removed or breaking changes).
- Flag anything that needs customers to act, such as a setting to change or a migration.
- If nothing customer-visible changed, post one line saying so.
Keep it under 25 lines and don't include code.

​

Make change summaries more useful

• Teach it your product’s language. Use /learn for the names customers see, for example “In customer-facing text, call an ‘org’ a ‘workspace’.” Once the format looks right, ask the agent to save it as a skill so every summary follows it.
• Add buttons for the next step. End the instructions with “Add buttons: Draft customer email (rewrite this as an email to customers), Sales talking points (rewrite the New items as three talking points) and Help center updates (list the help articles that may need updating).”
• Make sure the right people see breaking changes. Add to the instructions: “If anything is in Heads-up, also post it to #cs-leads.”
• Link the request behind each change. With Linear or Jira connected, each item can link its ticket, so CS can tell the customers who asked for it.
• Close the loop with Support. With Zendesk, Intercom, or Pylon connected, add: “For each item under Fixed, list open tickets that describe the same problem.” Support can then follow up with those customers.
• Answer follow-up questions in the thread. Anyone in the channel can reply with @coderabbit and a question, such as “does the export fix apply to self-hosted?” Pair this with the question automation for questions that come up later.

​

What’s next