> ## 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.
# Use the Control Tower
> Turn on the Control Tower, read its brief and findings, act on them or open a fix pull request, and dismiss what you do not need.
export const Plan = ({tier}) => {tier} plan;
The Control Tower is an agent that watches your estate on a schedule. It cuts alert noise (flapping, ignored and overlapping rules), looks for problems no alert covers, and writes up what it finds as findings you can act on. Nothing happens to your systems until you apply a finding, unless you choose a more assertive setting.
## Turn it on
Click **Control Tower** in the sidebar. Until it is enabled, the page says "The overseer is off."
Scroll to the **Settings** card. Organization admins see it, and members can read findings and act on them.
Tick **Enabled**. Pick a **Cadence** (daily or weekly) and an **Aggressivity**:
| Aggressivity | What the Control Tower may do |
| - | - |
| **Conservative** | Reports and recommends only. |
| **Balanced** | May also open investigations quietly. |
| **Assertive** | May also mute noisy rules for a limited time and file alerts. |
**Max tokens / run** caps how much AI work one run can use.
**Send a digest after each run** posts a short Slack report. **Open a ticket for each critical finding** is on by default. Click **Save**.
An organization admin can click **Run now** at the top of the page. The first scheduled run follows your cadence.
## The morning brief
After each run, the page shows what the Control Tower found:
* **State of the system** counts findings that are open, critical, high, recurring and ready to act on, with the age of the oldest. A line underneath shows how many are new and how many resolved since the last run.
* **Improvements worth scheduling** lists open findings that keep coming back, worst first. These are the ones nobody has got to yet.
* **What the overseer saw** is the run's written brief, with the time of the run.
With **Send a digest after each run** on, the same news arrives in Slack as an **Overseer report**, grouped by the team that owns each finding, with an **Open Control Tower** button. A quiet run posts nothing. The digest goes to your Slack info channel.
## Work through findings
The **Findings** card lists them grouped by service, worst group first, with a **Not attributed to a service** group at the end. Each finding shows its kind, severity, how many times it was seen and the Control Tower's confidence. Use the filter to switch between **Open**, **Dismissed**, **Actioned**, **Auto actioned** and **Resolved**. Links such as **Open Efficiency →** or **Open synthetics →** take you to the page where the finding can be fixed.
Each open finding offers some of these buttons:
| Button | What it does |
| - | - |
| The recommended action, named for what it does: **Mute this rule**, **Investigate this**, **Raise an alert**, **Alarm on this** | Applies the Control Tower's recommendation. **Alarm on this** opens a pull request for a missing CloudWatch alarm and needs an organization admin. |
| **Dismiss** | Closes the finding for good (see below). |
| **Draft runbook** | Starts a runbook for the problem, pre-filled from the finding. Shown when no runbook is linked yet. Admins only. |
| **Create fix PR** | Asks for a fix as a pull request. Shown when the finding names a service. Admins only. |
| **Create ticket** | Opens a ticket from the finding on your ops board. |
Once a finding has been acted on, it shows what was done and who did it. To handle a batch, tick the boxes on the left, or the box at the top of a service group, and click **Dismiss selected**.
## Apply a finding as a pull request
Click **Create fix PR** on a finding. SRE Agent reads the repository mapped to that service and prepares a pull request, with the finding as the brief. The page says it is analyzing the request, and the outcome appears here and in Slack. Pull requests are never merged for you. Review and merge them yourself.
The **Remediation PRs** card lists recent pull requests and their state. Click one to open a drawer with the agent's reasoning, the request it was given and the files it touched. If a pull request is blocked, the drawer explains why. Fix pull requests need the GitHub App connected for the repository, and are part of the Business plan.
## Dismiss a finding
Click **Dismiss**, enter a reason in **Why?**, and click **Dismiss**. The reason is optional, but the next person who sees the same problem will want it, for example "expected during the migration". A dismissed finding is not raised again. Find it later by setting the filter to **Dismissed**.
## More
Critical findings open a ticket on your ops board by default, and organizations with several workspaces get a merged findings view. Both are covered in [Control Tower details](/guides/prevent/control-tower-details).
## Related
* [Write and run runbooks](/guides/prevent/runbooks): the runbook a finding can start.
* [Request a fix as a pull request](/guides/fix/fix-requests): how a fix pull request is made.
* [Track work on the ops board](/guides/respond/ops-board): where critical findings land as tickets.
* [Plan matrix](/guides/reference/plan-matrix): which plans include the Control Tower.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.