> For the complete documentation index, see [llms.txt](https://docs.cortex.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortex.io/improve/opex-review/configuring-opex.md).

# Configuring OpEx Review

Steps for configuring OpEx Review

You control what metrics the agent pulls and how often it generates an analysis. Add the metrics you want to track under each [DRIVE pillar](/solutions/drive-framework/the-drive-pillars.md) then drag to reorder them or edit and remove any metric from its row. Choose which parts of your organization the report covers and set a generation cadence. Save the configuration, and the agent starts generating reports on that schedule.

{% hint style="info" %}
As a Research Preview feature, OpEx Review is still evolving, and some options may change. Share feedback with your Customer Success Manager or through the in-product feedback controls.
{% endhint %}

## Configuring OpEx Review

`Admins` and users with the `Configure OpEx` permission can configure OpEx Review. 

Before you run OpEx Review, decide which metrics it should include. Cortex pre-populates some metrics based on the integrations you've installed: deployment frequency, cycle time, incident frequency, and time to resolution. Follow the steps below to replace these metrics or select new ones.

1. From the main sidebar, select **OpEx Review**.
2. In the upper-right corner of the page, click **Edit**.
3. On the **Edit report** page, configure the following:
   1. In the **Set report scope** section:
      1. **Report type** - Select a report type from the dropdown. This controls how the report is organized and which teams get a separate report of their own.
         1. **Team report** (default) - Metrics are broken down by team throughout the report. All teams in your workspace are included by default, so you can compare teams and drill into any of them from one place. You don't need to select teams individually to see per-team metrics. The report breaks down by team either way. Select **Specific teams** when you want one of the following:
            * To narrow the report to part of your organization, choose a single high-level team, e.g. Engineering. Its child teams are included automatically and roll up into it.
            * To give teams their own reports, choose up to 10. Each one gets a dedicated report with insights written about that team, alongside the aggregate report covering all of them.
         2. **Domain report** - Works the same way, organized by domain instead of team. All domains are included by default. Select **Specific domains** when you want one of the following:
            * To narrow the report to part of your organization, choose a single high-level domain. Its child domains are included automatically and roll up into it.
            * To give domains their own reports, choose up to 10. Each one gets a dedicated report with insights written about that domain, alongside the aggregate report covering all of them.
   2. In the **Choose metrics** section:
      1. Cortex starts you off with default metrics for the Delivery pillar, and for the Reliability pillar when the required integrations are installed. Adjust those defaults and add metrics to any pillar you want to track. 
         1. Click **Add metric**. The **Metric definition** side panel opens.
            1. Select a metric from the dropdown. Cortex recommends metrics where available, or you can choose any out-of-the-box Eng Intelligence metric, custom metric, or Scorecard.
            2. Click **View metric**. The metric is added to the pillar.
            3. If you're running a team report, an extra option appears in the side panel. Select **Entity owner (Team)** or **Team (Author)** to define what "team" means for each metric. You can set this per metric, so a single report can use ownership for reliability and authorship for delivery.
               * Choose **Entity owner (Team)** when you're asking about the health of what a team owns. This is usually the right choice for reliability and quality metrics, where you want incidents and failures to land with the team responsible for the service, regardless of who touched it last.
               * Choose **Team (Author)** when you're asking about what a team is producing. This is usually the right choice for delivery metrics like deployment frequency and cycle time, where you want to see a team's own output rather than activity on their services by others.
               * **Example**
                 * An engineer on the Platform team opens a pull request against a service owned by the Payments team.
                   * With **Team (Author)**, the PR counts toward Platform.
                   * With **Entity owner (Team)**, it counts toward Payments.
         2. To reorder metrics within a pillar, drag them by the **grip icon**. To edit or remove a metric, click the **pencil** or **trash icon** in its row.
         3. Repeat as necessary.
   3. In the **Set schedule** section:
      1. Select how often the report should be generated. By default, reports are set to generate every two (2) weeks on Monday.
         1. **Start date** - The date report generation begins.
         2. **Report period** - How much data prior to each run date the report includes, in days or weeks. This also sets the cadence, so a two-week period generates a report every two (2) weeks.
         3. **Repeat on** - The day of the week the report generates.
4. Do one of the following:
   1. Click **Generate now** to run the report immediately. The configuration is saved automatically. A confirmation window opens showing the run date and the period the report covers. Click **Generate**.
   2. Click **Save and close** to save the configuration without running a report.

{% hint style="info" %}
Manually generated reports can only be produced once a day. The limit resets at midnight UTC. Scheduled runs do not count against the limit. If a run is already in progress, **Generate now** is unavailable until it completes.
{% endhint %}

### What happens after you save

The agent runs analyses on the schedule you set, beginning on your selected start date. You don't need to do anything between runs.

Each report covers the window ending on its run date and extending back by the report period value. Because that same value sets the cadence, consecutive reports run back to back with no gaps or overlap. The report summary in the left pane of the **Edit report** page shows the exact dates the next report will cover.

<div align="left" data-with-frame="true"><figure><img src="https://826863033-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJW7pYRxS4dHS3Hv6wxve%2Fuploads%2FYC3keYcAOMbufpZWFOUH%2Fopex-report-overview.png?alt=media&amp;token=c0b0e06a-e8c4-4d5e-a1ba-a53e5916f497" alt="The &#x27;Report summary&#x27; section." width="150"><figcaption></figcaption></figure></div>

Report dates are shown in UTC so they match the dates queried, and scheduled runs start at midnight UTC on the day you choose.

While the agent generates the report, a status banner appears at the top of the OpEx Review page showing the period the upcoming report will cover. When generation finishes:

* If you started the run with **Generate now**, the report opens automatically.
* If it was a scheduled run, click **View latest report** in the banner.

### Changing the configuration later

You can edit the configuration at any time. However, the change does not take effect the same way in every view:

* The **summary** of an already-generated report doesn't change. It's a snapshot of what the configuration tracked when that report ran. Newly added metrics appear in the summary starting with the next generated report.
* The **Metrics by** and any custom dashboard tabs rebuild from your current configuration, so past reports show your new metrics there too.

Once Cortex generates your first report, see [Using the OpEx Review report](/improve/opex-review/using-opex.md) to read the executive briefing, break metrics down by team, and share the report.