> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sreagent.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Request a fix as a pull request

> Install the GitHub App, ask for a fix in plain words, and review the draft pull request SRE Agent opens.

export const Plan = ({tier}) => <Badge color="blue">{tier} plan</Badge>;

SRE Agent turns a plain-words request into a pull request, or into a reasoned decline, against a repository you chose. A person always reviews and merges the result: nothing is merged for you and nothing is pushed to your default branch. Fix requests need the Business plan.

<Plan tier="Business" />

## Install the GitHub App

<Steps>
  <Step title="Open the GitHub tab">
    Go to **Integrations**, open the **GitHub** tab, and find the **GitHub App: remediation PRs** card. You need to be an organization admin.
  </Step>

  <Step title="Install the App">
    Click **Install on GitHub**, choose the repositories to grant, and finish on GitHub. You land back on the card, now connected. If the App is already installed on your GitHub account, click **Already installed? Find it** instead. It lists the installations your linked GitHub account administers, so sign in with GitHub once from the sign-in page first.
  </Step>

  <Step title="Choose how it behaves">
    Under the connected card, set the toggles that fit your team:

    | Toggle | Default |
    | - | - |
    | **Auto-open PRs from resolved investigations** | Off |
    | **Auto-revise once when a reviewer flags a PR** | Off |
    | **Open as draft PRs** | On |
    | **Review pull requests for reliability and security** | Off |
    | **Comment on linked pull requests** | On |
  </Step>

  <Step title="Map repositories to services (optional)">
    Every repository the App can reach can already receive a fix request. In **Repository settings (optional)**, click **Add settings** to give a repository a **Service alias**, pin a **Branch**, set the **Path prefix for remediation**, or narrow the **Writable extensions**. Fixes only write inside that fence.

    Under **Sending fix requests** in the same card, choose **Wait for a person** for a repository and its requests wait until someone clicks **Send** on the card (or in the request's Control Tower drawer). The default is **Send automatically**.
  </Step>

  <Step title="Add a context repository (optional)">
    Under **Context repo (grounds fix requests)**, pick a repository that holds your runbooks, known failure modes and conventions. The agent reads it before proposing a change. Its content goes to your configured AI provider, like the target repository's files. Choose **(none)** to clear it.
  </Step>
</Steps>

## Ask for a fix

Any of these starts the same request:

* In Slack, run `/sre-fix [service|repo] <what to fix> [files: a.tf, b.tf]`. The service or repository is optional; without one the agent picks during analysis or declines if nothing fits. The outcome replies in the channel where you ran the command.
* On an ops board card, click **Auto-remediate** under **Act on this**.
* In the Control Tower, click **Create fix PR** on a finding.
* From any script or workflow tool, post to the intake webhook below.

<Note>
  Each repository accepts at most 5 open fix pull requests. Review or close some before asking for
  more.
</Note>

## Send a request with the webhook

Use this when no ticket system is in the loop. Find your webhook token on the **Integrations** page, **Webhooks** tab, in the **This organization's webhook token** card, and treat it as a secret: anyone holding it can queue fix requests against your repositories.

```bash theme={null}
curl -X POST https://sreagent.app/webhooks/fix-requests/<your-webhook-token> \
  -H 'content-type: application/json' \
  -d '{
    "description": "grant the deploy role read on the artifacts bucket",
    "service": "checkout",
    "requested_by": "oncall-workflow",
    "dedup_key": "workflow-run-8123"
  }'
```

| Field | Required | Meaning |
| - | - | - |
| `description` | Yes | What to change and why, in plain words. |
| `title` | No | Short pull request title. Defaults to the description. |
| `service` | No | A service alias, or a repository as `owner/name`, a short name, or its GitHub URL. |
| `repo` | No | Same values as `service`. Sending both with different values is refused. |
| `requested_by` | No | Shown on the request and in the pull request body so a reviewer sees who asked. It grants nothing. |
| `ticket` | No | An external ticket id, shown to the agent as evidence. |
| `dedup_key` | No | Sending the same key again replaces the earlier request instead of opening a second one. |
| `files` | No | Up to 10 repository paths to start from. They never widen the write fence. |

A `202` response with `{"status":"analyzing","id":"<uuid>"}` means the request is queued, not that a pull request will follow. A `422` means it was refused before analysis, with the reason in the body: for example no description, no GitHub App installed, a target that matches no repository, or a plan without fix requests. A `404` means the token is not valid.

## What happens next

The request moves through **analyzing** to **open** (a draft pull request exists), **declined** or **failed**, with the reasoning attached. Follow every request in the Control Tower.

* The pull request is a draft while **Open as draft PRs** is on. It names who asked and links back to the card. When SRE Agent's own agent runs the fix, the branch is named `sre-agent/...`.
* Sending the same `ticket` or `dedup_key` again closes the earlier open pull request on GitHub and replaces it with a fresh analysis.
* Slack gets the outcome. Requests with no channel of their own post to the **Remediation Channel** under **Settings**, **Notifications** (in the Slack section), or to your Info channel when that is blank.
* To change a request after the outcome, mention the bot in the thread under the outcome message with what you want different. You confirm with a button, and a follow-up run supersedes the open pull request.

## Review pull requests

Turn on **Review pull requests for reliability and security** and every pull request in your selected repositories gets inline comments plus one summary comment. Anyone with write access can also ask for a review by commenting `@sre-agent review` on a pull request. **Comment inline at this severity and above** sets the floor; lower findings go in the summary.

<Warning>
  The review is always a comment. It never approves a pull request, never requests changes, and
  never blocks a merge.
</Warning>

## Where fixes run

By default SRE Agent's own agent runs the fix. Teams can instead run fixes in their own CI or on their own machine, chosen per repository under **Integrations**, **GitHub**, **Repository settings**. Only admins can change it, and the choices appear when your plan includes them.

## Related

* [Quickstart](/guides/get-started/quickstart): start here if no alerts are flowing yet.
* [Improve your alert rules](/guides/fix/alert-suggestions): fix the alert rule behind a noisy alert.
* [Run and read an investigation](/guides/respond/investigations): the diagnosis a fix request starts from.
* [Plan matrix](/guides/reference/plan-matrix): which plans include fix pull requests.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.