> 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/solutions/drive-framework/running-an-opex-review.md).

# Running an OpEx Review

An **OpEx (Operational Excellence) review** is the recurring meeting where engineering leadership looks at how the org is actually operating. [**DRIVE**](/solutions/drive-framework/the-drive-pillars.md) is the framework that gives the review its structure: instead of measuring individual developer output, it measures whether your organization is sustainably turning customer needs into software, across five pillars: **Delivery, Reliability, Initiatives, Vigilance,** and **Efficiency**.

If you've tried to run one, you know the problem: pulling those metrics together from a dozen different tools takes real time before the meeting even starts. Once you have the metrics, it's easy to lose the signal in all that data, making you unable to tell what actually matters this week from the noise around it, while last cycle's action items quietly fall through the cracks.

Cortex's OpEx Report is built to solve both problems. It pulls metrics from the tools you already use, rolls them up by team or domain across the DRIVE pillars, and surfaces what actually needs attention, so the review itself is about decisions, not data-gathering.

### How it works

#### 1. Configure your report

Tell Cortex what to measure and who it's for.

1. **Set your scope.** Choose team tree or domain tree, and whether the report covers your whole org or a filtered slice of up to 10 teams or domains.
2. **Choose your metrics.** Cortex pre-populates some defaults based on the integrations you already have connected. Add more for any DRIVE pillar from an out-of-the-box Eng Intelligence metric, a custom metric, or a Scorecard.
3. **Set your schedule.** Match it to how often you actually run the review, weekly or biweekly for most teams.
4. **Generate now**, or save and let it run on schedule.

See our [OpEx Reporting documentation](/improve/opex-review/configuring-opex.md) for a detailed guide on setting up the OpEx report.

#### 2. Generate and read the report

Each cycle, Cortex generates a report with an AI-written overview of what improved, what regressed, and where to focus, followed by pillar-by-pillar metric cards with a trend chart and an AI insight on each one.

#### 3. Dig into anomalies live, in the meeting

The question that used to become a post-meeting follow-up ("which team is driving this spike?") doesn't have to leave the room anymore. Every metric card and the report overview have an **Explore** link into Cortex AI, pre-loaded with that metric's context, so you can ask follow-up questions and get an answer without breaking the meeting's momentum.

#### 4. Build the views each audience needs

The OpEx Dashboard gives you the seeded rollup table out of the box. Duplicate it to add your own charts and KPI cards, or bring in existing custom dashboards as additional tabs: useful when your org-wide review and your local team reviews need different levels of depth.

#### 5. Turn insights into owned action items

A review that only produces a status update hasn't done its job. Anomalies you surface in the report should turn into Initiatives with named owners and due dates, and your Initiative completion rate is itself a DRIVE metric worth tracking, since it's the check that the review is actually changing what teams work on.

### Setting up your review cadence

A generated report doesn't run itself. Keep these in mind when you set up the meeting:

* **Make it unmissable.** Weekly or biweekly, same time, doesn't move for a busy sprint. If leadership is too busy to review the metrics, that's usually a sign the review matters more, not less.
* **Give it a facilitator.** Fixed or rotating, the facilitator's job is to interrogate the data, not just present it, and to make sure action items from the last review actually got done.
* **Focus on anomalies, not everything.** Green metrics get a mention; red and degrading metrics get the room's time.
* **Keep it blameless.** The review should target system problems, not individual ones.

The right format depends on your size:

|                 | Startup / Mid-Market                            | Enterprise: Local Team                              | Enterprise: Org-Wide                                                                        |
| --------------- | ----------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| **Cadence**     | Weekly, 60 min                                  | Weekly or biweekly, 30 min                          | Weekly or biweekly, 60 min                                                                  |
| **Attendees**   | VP Eng, EMs, tech leads, off-going on-call      | Open invite within the team                         | VPs, Directors, EMs, tech leads, off-going on-call across domains                           |
| **Aggregation** | Team or domain level                            | Per service                                         | Team or domain level                                                                        |
| **Focus**       | Full DRIVE report, critical + secondary metrics | Inward-facing report, non-curated SLOs, pager noise | Critical metrics only, major anomalies, a randomly selected team or service for a deep dive |

### Getting started

If you're standing up your first OpEx review, don't try to populate all five pillars on day one.

1. **Pick two pillars to start with**, for most orgs, Delivery and Reliability, since they naturally counterbalance each other.
2. **Use the metrics you already have.** If you don't have any yet, start with the simplest ones available and run the review to build the habit before optimizing the metric set.
3. **Expand to the other pillars** once you have reliable visibility into your first two.
4. **Go deeper** into secondary metrics as specific pillars become pain points.

{% hint style="success" %}
Looking for more? Check out the [Cortex Academy](https://academy.cortex.io/) video on using the OpEx report.
{% endhint %}