As a Public Beta 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.
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.
- From the main sidebar, select OpEx Review.
- In the upper-right corner of the page, click Edit.
- On the Edit report page, configure the following:
- In the Set report scope section:
- 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.
- 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.
- 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.
- 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:
- 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.
- In the Choose metrics section:
- Metrics are grouped into six sections: Overview (Are there things we want to highlight?), then the five DRIVE pillars—Delivery, Reliability, Initiatives, Vigilance, and Efficiency. Overview sits above the pillars and holds what you want read first. Cortex starts you off with default metrics for the Delivery and Reliability pillars when the required integrations are installed. Adjust those defaults and add metrics to any section you want to track.
- Click Add metric. The Metric definition side panel opens.
- Select a metric from the dropdown. You can choose any out-of-the-box Eng Intelligence metric, custom metric, or Scorecard. If you have a Datadog integration, you can also add an SLO summary to the report alongside your metrics.
- Click View metric. The metric is added to the pillar.
- 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.
- An engineer on the Platform team opens a pull request against a service owned by the Payments team.
- Optionally, select an Operation to set how the metric’s data points are combined into a single value for the report period. Options include Average, Sum, Max, Min, Median, and P95.
- For custom metrics, you can also select Latest. Instead of combining data points across the report period, Latest returns the most recent data point within it. If the period has no data points, the metric shows no value.
- Use Latest for status-style custom metrics where only the current state matters, e.g. a metric that records
1when a team’s on-call rotation is set up and0when it isn’t. Averaging that kind of metric across the period would blur the team’s actual current state. - Latest isn’t available for out-of-the-box Eng Intelligence metrics or Scorecards.
- Optionally, add filters to narrow this metric’s query. Because filters are per metric, you can add the same metric more than once and split each copy differently, e.g. Sev 0 incidents in one card and Sev 1 in another.
- To reorder metrics within or between pillars, drag them by the grip icon. To edit or remove a metric, click the pencil or trash icon in its row.
- Repeat as necessary.
- Click Add metric. The Metric definition side panel opens.
- Metrics are grouped into six sections: Overview (Are there things we want to highlight?), then the five DRIVE pillars—Delivery, Reliability, Initiatives, Vigilance, and Efficiency. Overview sits above the pillars and holds what you want read first. Cortex starts you off with default metrics for the Delivery and Reliability pillars when the required integrations are installed. Adjust those defaults and add metrics to any section you want to track.
- In the Set schedule section:
- Select how often the report should be generated. By default, reports are set to generate every two (2) weeks on Monday.
- Start date - The date report generation begins.
- 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.
- Repeat on - The day of the week the report generates.
- Select how often the report should be generated. By default, reports are set to generate every two (2) weeks on Monday.
- In the Set report scope section:
- Do one of the following:
- 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.
- Click Save and close to save the configuration without running a report.
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.
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.
- 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.