Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Ship reliable software, faster, with AI
Cortex is the AI-powered internal developer portal (IDP) that helps engineering teams ship reliable, secure, and efficient software, faster. It uses AI to make sense of your engineering data, figure out the next unlock for your team, and solve it — all in one place.
Get started in minutes with Cortex's .
See an overview of Cortex below:
We believe the foundation for Engineering Excellence starts with clear ownership and accountability. With ownership in place, drive complete visibility through the catalogs, a culture of continuous improvement using and , and consistent developer experience through self-service .
Learn how organizations drive Engineering Excellence with Cortex:
The Cortex YAML linter validates your cortex.yaml files for both general YAML syntax and Cortex-specific schema requirements, helping prevent ingestion of invalid or incomplete data into the platform.
This page references the built-in tool in the Cortex UI under Tools > YAML Linter. Note that there is also a linter tool built in to the Cortex GitHub app, which runs checks on pull requests when you use GitHub in a .
In this section, learn how to add each of the built-in entity types and dependencies, and how to create a custom entity type and add custom entities:
Eng Intelligence Dashboards provide engineering leaders and teams with real-time visualizations into key metrics, velocity and productivity trends, incident and quality insights, and historical organzation-wide rollups. Dashboards are natively integrated with your Cortex catalog, Scorecards, and Initiatives, allowing you to move from insight to action.
See the documentation linked below to learn more about each dashboard:
: Visualize the four key DORA metrics: Cycle time, deployment frequency, change failure rate, and MTTR.
: Monitor version control metrics such as PR cycle time, PR size, and PR success rate, giving insight into your process efficiency and areas to target for improvement.
Want to learn more? Check out the Cortex Academy course on Catalogs, Entities, and Relationships, available to all Cortex customers and POVs.
Custom Dashboards: Build tailored dashboards by combining metric visualizations into a unified, shareable view.
Automate common tasks like scaffolding new services or handling migrations with Workflows.
Get quick answers about your workspace via Cortex MCP, allowing for faster decision making.
How do different personas drive velocity with Cortex?
Engineering leaders: Leverage the productivity metrics from Eng Intelligence during performance reviews and coaching conversations.
Platform engineers: Set up a Workflow to request access to commonly used tools, making the process a single approval flow that integrates into their existing tooling.
Automate repeatable tasks with Workflows.
How do different personas drive efficiency with Cortex?
Engineering leaders: Manage cloud costs and improve resource utilization with Scorecards.
Platform engineers: Use Scorecards to ensure standards are met during a migration, accelerating project timelines.
Developers: Use the Engineering homepage to gain insight into their tasks and priorities.
Ensure consistent rollouts and CI/CD processes using Workflows.
How do different personas drive security with Cortex?
Engineering leaders: Use reports to understand current security posture, allowing them to guide their teams with actionable insights.
SREs: Use Scorecards to maintain catalogs, enabling faster incident response.
Security engineers: Automate security checks and flag noncompliant services with Scorecards, ensure consistency and standardization of tasks with Workflows.
Enable fast response to incidents with Workflows to rollback, restart pods, and more.
Give leaders and engineers a shared view of Initiatives, progress, and tasks in the Engineering homepage.
How do different personas drive reliability with Cortex?
Engineering leaders: Use reports to get a unified view of organization-wide service health, allowing them to prioritize reliability Initiatives across teams.
Developers: Use Scorecards to gain clear visibility into whether their services meet standards for reliability.
SREs: Automate production readiness checks via Scorecards, allowing them to move from reactive fire-fighting to proactive incident prevention.
Platform engineers: Automate best practice enforcement via Scorecards. Use Iniatives to , ensuring reliability improvements are systematically addressed.
In Cortex, navigate to Tools > YAML Linter.
Paste your YAML into the text editor, then in the upper right, click Validate YAML.
At the bottom of the screen, you will see a status banner:
If the format is correct: You will see a message stating that the YAML is valid:
If the format is not correct:
For issues with the format of a Cortex-specific block, you will see a warning banner:
For errors that cause the YAML to fail the linter check (such as missing a title or x-cortex-tag), you will see a banner that includes the error message and which line is affected:
The linter checks for valid YAML structure and ensures required Cortex fields (like openapi version, x-cortex-tag, etc.) are present. If a required field is not present, this results in an error and the YAML does not pass the linter check.
The linter also validates the format of Cortex-specific blocks (e.g., x-cortex-groups, x-cortex-firehydrant) but does not verify the correctness of referenced data (such as whether a group or monitor ID actually exists). If there is an issue for a Cortex block, such as a block that doesn't contain a value, you will see a warning; however, the YAML will still pass the linter check.
If you submit a file with templating syntax (e.g., Jinja or cookiecutter variables like {{ variable }}), the linter will fail because these are not valid YAML until rendered. Only fully rendered YAML files will pass validation.
If the YAML is invalid or missing required fields, the linter will return errors indicating the line and nature of the problem.
If you are using GitHub in a GitOps workflow, you can adjust settings related to the linter. See GitOps Settings for more information.
Archiving an entity allows you to remove it from active use while preserving its history and context.
You can configure Cortex to automatically archive entities when they are no longer detected in your integrations or when their corresponding YAML files are deleted. We recommend enabling this feature to keep your data up-to-date without manual effort. Learn more in Auto archiving entities.
It's also possible to manually archive entities in the Cortex UI or via the Cortex API, as described below.
To archive entities, your user or API key must have the Archive entities permission. To unarchive entities, your user or API key must have the Configure entities permission.
Navigate to an in Cortex.
Click the 3 dots menu at the top of the page, then click Archive entity.
In the confirmation window, click Archive.
To un-archive an entity:
Archived entities are not included in the following Cortex features:
and
features, including CQL reports and query builder
By default, archived entities do not appear in the lists on "All entities" or in catalogs, but you can choose to include archived entities in your view.
To include archived entities:
Click Display at the top of the list.
Toggle on the setting for Show archived.
Note that this setting is not persistent when you navigate away from the page.
On an , if a related dependency, child entity, or parent entity has been archived, it will not be displayed under Relationships in the entity's sidebar.
If the entity itself has been archived, you will see an "Archived" flag appear next to its name:
While configuring an entity, you cannot add an archived team as an owner. You cannot add archived entities as dependencies or as parent or child entities.
Cortex will tag detected changes to signify whether an entity or repository has been archived. Learn more in .
The Cortex Terraform Provider acts as a bridge between Terraform and the Cortex platform, allowing you to manage and provision Cortex resources (such as Scorecards, integrations, and entities) using Terraform’s infrastructure-as-code approach. The provider is a wrapper around the public Cortex API and is maintained by the Cortex team, with shared ownership and ongoing support for customers who use it.
Many Cortex customers manage their entire service catalog and engineering standards as code using the Cortex Terraform Provider.
Expand the tiles below for examples on how to handle different use cases with this approach.
For installation instructions, see the .
See .
Humanitec offers products to build on top of your Internal Developer Portal (IDP) for containerized workloads.
Integrating Humanitec with Cortex allows you to run a Humanitec pipeline directly from Cortex.
Before getting started:
You should have an app with a working pipeline configured in Humanitec.
Create a service user in Humanitec, and create an for the service user.
Follow the instructions to and .
Add an HTTP request block to your Workflow. Configure the block:
Block name: Enter a descriptive name for the block.
Slug: Enter a unique identifier for the block.
Alternatively, you can also use an Async HTTP request block in your Workflow, using the to call back to Cortex.
At the top of your Workflow in Cortex, click Run.
In your Humanitec workspace under your app's pipelines, you will see the run listed under the Runs tab:
See the video below where a member of the Humanitec team walks through advanced end-to-end setup on AWS using Cortex, Humanitec as the orchestrator, and Terraform modules deployed via ECS runners. The video demonstrates detecting a policy violation and remediating it.
Rule filters allow you to apply a Scorecard rule only to specific entities. It's helpful to use a rule filter when a rule doesn’t apply to every entity or every group.
You can apply a filter in the Cortex UI while building out your Scorecard rules, or you can write a custom CQL query to filter your rule.
When setting up a rule for a Scorecard, click and expand Restrict rule to specific groups.
Select the relevant groups to include or exclude.
Or, if you prefer to write a CQL query, click Switch to CQL under the group fields.
Click Save rule.
See the for instructions on the overall process of creating a Scorecard.
You can also edit an existing Scorecard to add a filter to a rule.
For example, let's say that entities in the "billing" group don't need to have SLOs set up properly.
In the rule "Has SLOs set up," apply a filter to exclude the "billing" group:
After saving the rule with the excluded group, view the Scorecard. Any entities in the "billing" group will not be scored against the "Has SLOs set up" rule. The rule will not appear as a passing or a failing rule; it will not be included at all.
Once a rule filter has been applied, you can still see it on a Scorecard’s home page. Navigate to the Rules tab and expand the rule to confirm it has been exempted.
Cortex’s On-call Assistant leverages the to automatically surface the most vital information about entity health and metadata when an incident is triggered. On-call Assistant notifies the user(s) responsible for an incident via Slack, including information about the affected entity, recent deployments, ownership, and links to get more details, including dependencies, runbooks, and logs.
On-call Assistant helps users respond to incidents in real time, simplifying the incident response process and helping to reduce MTTR. It can also drive adoption and engagement through links to the catalogs and Scorecards.
Groups are a tagging system that can be used to group a set of together, enabling a variety of use cases including:
Tagging
Use groups to segment entities.
For example, you could segment by tiers (tier-0 to indicate high priority), type (backend, frontend, library, API), or language (Python, Java).
cortex_catalog_entity_custom_data – e.g. tier, business_unit, cost_center, “is_internally_facing”, etc.Optionally define departments (e.g. “Payments”, “Growth”) with cortex_department, and link services/teams to those for reporting and ownership.
rules (expressions, titles, weights, optional failure messages)
an evaluation window (how often to evaluate, min every 4 hours)
a filter to target specific entity types or groups
Use cortex_resource_definition to standardize external signals that Scorecards rely on (e.g. “has SLO in Datadog”, “has PagerDuty service”, “has runbook link”).
Manage changes to standards through Git review: PRs update the Terraform code, then Terraform updates the Cortex Scorecards and resources.
cortex_departmentdepartmentteamcriticalityWhen infrastructure changes (e.g., new API version, team moves between org units), updating Terraform automatically pushes the new OpenAPI spec + org metadata into Cortex.






Navigate to the archived entity's details page in Cortex.
Click the 3 dots menu at the top of the page, then click Unarchive entity.
In the confirmation window, click Restore.
See the API documentation on and .




HTTP method: Select POST.
URL: Enter a Humanitec API URL based on the Humanitec call createPipelineRun, e.g., https://api.humanitec.io/orgs/<your-Humanitec-org>/<your-app-ID>/pipelines/<pipeline-ID>/runs
At the bottom of the side panel, click Save.
Make any other necessary changes to your Workflow, then in the upper right corner of the page, click Save workflow.

When an incident is triggered in PagerDuty, On-call Assistant will notify relevant users via Slack. This alert will include information about the affected entity, deploy details, and ownership information so an on-call team member can reach out to other relevant parties about the incident.
Developers can access entity information that is already in Cortex directly from the Slack notification to quickly resolve issues. On-call Assistant provides a direct link to view the alert in PagerDuty, so you can also quickly access the incident from its source.
You must have the PagerDuty integration configured.
You must create an API key in PagerDuty with the Write permission.
If you create an API key with Read-only permissions, you will also need to configure a webhook to get the On-call Assistant working.
To enable, navigate to Settings > PagerDuty and toggle on Enable On-call Assistant.
If you added PagerDuty API key with Write permissions, enabling the On-Call Assistant will create a webhook subscription in PagerDuty, allowing Cortex to receive events when incidents are triggered, escalated, or unacknowledged.
If you added PagerDuty API key with Read-only permissions, you must also configure a webhook subscription.
In Cortex, on the PagerDuty settings page, click Configure webhook.
Copy the webhook URL. You will need this in the next steps.
In PagerDuty, add a new webhook.
Paste the Cortex webhook URL into the Webhook URL field.
Choose Account for scope type.
Select only the following in Event Subscription:
incident.escalated
incident.reopened
incident.triggered
A secret will be generated. Copy the secret. You will need it in the next step.
Navigate back to the browser window where your Cortex instance is open. In the Webhook configuration Secret field, enter the secret that you generated in PagerDuty.
Click Save at the bottom of the side panel.
Filtering throughout Cortex
Use groups to include or exclude certain entities from Scorecards, catalogs, CQL reports, and more.
For example, you may want a Scorecard to only apply to Python services or a catalog that only shows tier-0 services.
Reporting
You could aggregate Scorecard scores by a specific group, such as a tier.
For example, viewing a Production Readiness Scorecard broken down by tier.
While viewing an entity, its groups are listed in the upper right side of the page:
Click the group name to view a list of all other entities that are tagged with this group.
You can create new groups in an entity's YAML, directly in the Cortex UI, or via the API. When creating a new group, it is applied to the entity where you are creating the group.
Note the following considerations:
If a group has been set in the entity descriptor YAML, an API call will not overwrite the existing value.
Groups created via the API will not appear in the entity descriptor YAML.
Groups created via the API cannot be removed via the Cortex UI.
To create a group in the UI:
Navigate to the entity that you want to apply a group to.
Click the magnifying glass icon at the bottom of the main nav, or click Catalogs > All entities and search for the entity from that page.
In the upper right corner of the entity page, click Configure entity.
Click into the Groups field.
To apply an existing group, type to search then click on the group.
To create a new group, type the group name into the field, then click the group name in the dropdown. The group will be created and applied to the entity.
At the bottom of the page, click Save.
Groups are defined as a list of tags.
Groups may not contain whitespace characters.
You can use the API to add groups to an entity. See the .
To determine whether or not to use groups or custom data, consider whether your use case would be considered "tagging" with a definite enum of values (backend vs frontend), or more freeform metadata availability-zones: [east, west].
There is no difference between these. x-cortex-service-groups has been deprecated in favor of x-cortex-groups, but the change is backward-compatible.
Okta is an identity and access management (IAM) platform. Integrate Cortex with Okta to drive insights into authentication and ownership.
After configuring the integration, you can set Okta teams and team members as owners of entities.
For information on configuring Okta SSO or Okta SCIM for logging in to Cortex, see the Okta SSO documentation and Okta SCIM documentation.
Before getting started:
An Okta administrator, with at least the permissions, must .
Grant the following scopes for the API token:
okta.groups.read
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select Okta.
Click Add configuration.
Configure the Okta integration form:
See the for instructions on importing entities.
Team data syncs from Okta daily at 3 p.m. UTC.
The group name is case-sensitive and should be exactly the same as in Okta.
With the Okta integration, you can create Scorecard rules and write CQL queries based on Okta teams.
See more examples in the in Cortex.
Cortex conducts an ownership sync for Okta teams every day at 3 p.m. UTC.
I've added an API token but the login is still using Google.
To set up Okta for SSO, use the .
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Grafana is an open-source observability platform that provides monitoring and visual analytics for application performance. Use Grafana to visualize your data, from bar charts and histograms to pie charts and geomaps.
Integrating Grafana with Cortex allows you to:
View Grafana charts on entity pages in Cortex
Create Scorecards that include rules related to Grafana dashboards
Before getting started:
Your Grafana dashboard must have .
Your OR if you are on a instance, then Cortex and Grafana must be accessible within the same private network (such as a VPN).
You will need the public embed link provided in the iframe snippet.
Define the public embed link in the for each entity where you want to embed a chart.
For the entity where you want to embed a chart, open its YAML file.
You can do this locally if following a approach, or you can edit a YAML file directly in the Cortex UI on the .
Add the x-cortex-dashboards block. Include the type (grafana) and the url
Repeat the steps above for each entity you want to add a Grafana chart to.
Once you've defined the chart in an entity's YAML, you can view the graphs from an .
In an entity's sidebar, click Dashboard. All charts defined in the entity descriptor will be embedded on this page.
With the Grafana integration, you can create Scorecard rules and write CQL queries based on Grafana charts.
See more examples in the in Cortex.
Grafana charts are updated in real time.
I've correctly added the embed URL, but the graph is showing an error or a blank screen.
You may need to in your Grafana instance.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Coralogix is an observability and security platform. Integrate Cortex with Coralogix to drive insights into alerts.
After setting up the integration, relevant alerts from Coralogix will appear in your entity pages. While viewing an entity, click Integrations > Coralogix in its sidebar to view the list of alerts.
Before getting started, generate a .
In Cortex, navigate to the
Click Integrations from the main nav. Search for and select Coralogix.
Click Add configuration.
Configure the Coralogix integration form:
By default, Cortex will use the entity name or (e.g. my-service) as the "best guess" for the Coralogix alert application name. For example, if your entity name is "My Service" and your Cortex tag is “my-service”, then the corresponding application name in Coralogix should be “My Service” or "my-service".
If your Coralogix application names don’t cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
Coralogix alerts can be listed in the Catalog under the Coralogix section. We support application names in the YAML for pulling Coralogix alerts.
With the Coralogix integration, you can create Scorecard rules and write CQL queries based on Coralogix alerts.
See more examples in the in Cortex.
IBM Instana Observability is a tool used for monitoring and performance management. Integrate Instana with Cortex allows you to pull in services from Instana.
Before getting started, .
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select Instana.
Click Add configuration.
Configure the Instana integration form:
Cortex automatically syncs from Instana APM at 7 a.m. UTC.
See the for instructions on importing entities.
Cortex will pull recent changes from Instana into the . Here, you can find new entities in Instana that have not been imported into the catalog.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
JQ is a lightweight, flexible command-line JSON processor that allows users to do arbitrary JSON manipulations.
Cortex leverages JQ within CQL to enable complex queries, including queries on YAML files. For instance:
The above query would cycle through the foo object and retrieve the length of all .property components. This type of query is often used on Kubernetes resources.
JQ can provide additional flexibility around data types. For instance, let's say you have a string associated with a numerical value in your Custom Data.
If you wanted to query on the line value as a number rather than string, the following JQ functionality could be used within CQL:
This would result in the respective entity passing this CQL check.
The following examples demonstrate ways you could use JQ in Cortex:
This checks if custom git data exists, uses the custom dockerfile path if present, or falls back to the default "Dockerfile" path.
Use bracket notation to access JSON properties containing dots, slashes, or other special characters:
Prevent errors by checking for null values before accessing properties:
For Scorecard rules, you can use a similar approach:
Find packages containing specific strings using the matches() function:
Filter team members by role using JQ:
When working with complex YAML files like GitLab CI configurations:
Or, for nested metadata:
This query extracts the version number from a Maven pom.xml file. You might use this to automate dependency version checks:
This query would allow you to display a parent entity name value, rather than an array, in a CQL report:
You may have over a hundred repositories in GitHub, and eventually, you will likely import all of them into Cortex. This much information can make it difficult to know at a glance that all repositories are accounted for and all new projects are being imported into and tracked within Cortex.
The discovered entities list (formerly known as the discovery audit) guarantees confidence in your catalogs by listing all changes that Cortex has detected. Cortex compares everything that exists within the system to what it discovers within your git tool, APM tool, Kubernetes cluster, and other crucial integrations, giving you insight into changes happening across your environments.
You can view discovered entities under Catalogs > All entities in the Discovered entities tab.
On this page, see a list of recent changes in your environment that aren't yet reflected in Cortex, including newly created repositories, services, and resources discovered from your integrations.
The first time you view the discovered entities list, there may be a lot to review. To narrow the scope of your list and start with changes that are the highest priority for you, search or filter the list by integration or entity type.
To search, enter text into the search bar in the upper right corner of the list.
To filter, click Filter in the upper right corner of the list. Select your filtering criteria, then click Apply.
Cortex will tag detected changes to signify whether an entity or repository has been discovered, archived, or deleted.
You can import, delete, or ignore the entities listed in Discovery audit.
If Cortex detects a new service or resource, you can import it directly from this page:
Click + in the row containing the new entity:
Configure the entity details.
For detailed instructions on creating a new entity, see the relevant docs page for the entity type: , , .
If Cortex no longer detects a given entity, you also have the ability to delete that entity or repository directly from this page:
Click the trash can icon in the row containing the entity:\
In the confirmation window, click Delete.
The confirmation window gives you the opportunity to review all potentially impacted services before deleting, so you don’t unintentionally remove something from Cortex.
If an event appears within the discovered entities list, but is irrelevant — for example, a test project that doesn’t need to be imported into Cortex — you can ignore it:
Click the hide icon in the row containing the entity:\
The entity will now appear in the Ignored tab. The ignore action is persistent, so the event won’t appear again within the discovered list.
From the ignored list, you can move the entity back to the Discovered tab by clicking the eye icon.
Cortex supports a subset of integrations within the discovered entities list:
Datadog
ECS
Version control (Azure DevOps, Bitbucket, GitHub, GitLab)
Instana
is an open source automation server which enables developers to build, test, and deploy software.
Integrating Jenkins with Cortex allows you to:
Send information about Jenkins deploys into Cortex
This data appears on .
Use
Getting your data into Cortex is the foundation for data-driven decision making and improved accountability across your teams.
By connecting your services, repositories, teams, infrastructure, and more, Cortex can provide a complete, up-to-date view of your ecosystem. This powers the ability to track ownership of entities, enforce production readiness and other standards via , standardize common developer for entities, and more. It also ensures your developers can find what they need, understand how everything fits together, and make better decisions at every stage of the development lifecycle.
Some internal developer portals start with too much rigidity or too little guidance. A rigid platform prevents you from correctly modeling relationships between key entities in your environment. An overly modular approach requires you to rebuild business logic for each use case, resulting in the same fractured experience you intended to solve for.
is continuous integration and continuous delivery platform that can be used to implement DevOps best practices.
Integrating CircleCI with Cortex allows you to:
in Cortex
Create that track progress and drive alignment on projects involving your CircleCI data
Use Scorecards to establish best practices, track migration, promote accountability among teams, enforce standardization across entities, or define maturity standards.
Define
First, you create a Scorecard to set rules and define standards.
Learn more: .
Assess
jq(custom("foo"), ".property | length")Click Confirm import.
Lighstep
New Relic





incident.unacknowledged






x-cortex-custom-metadata:
my-key:
line: "100"jq(custom("my-key"), ".line | tonumber") > 99git.fileContents(jq(custom("git"), "if . != null then .[\"dockerfile-path\"] else \"Dockerfile\" endjq(k8s.spec().firstOrNull().selector.matchLabels, ".[\"app.kubernetes.io/instance\"]")jq(custom("data-key"), 'if .retryConfigurations != null then .retryConfigurations | map(.retryAttemptTime) else "Not Found" end')custom("retry-circuit-breaker") != nulljq(custom("data-source").packages.filter((package)=>package.packageName.matches(".*<string-text-here>.*")).map((package) => package.packageVersion), ".")jq(entity.descriptor().info.`x-cortex-team`.members, "map(select(.role == \"engineering-manager\")) | .[].name")jq(git.fileContents('gitlab-ci.yaml').split(' ').filter((section) => section.matchesIn('NODE_VERSION:')).firstOrNull(), '.variables.NODE_VERSION')jq(aws.details(), ".resources[0].Scheme")jq(aws.details(), ".resources[0].metadata.Scheme")jq(jq(git.fileContents("pom.xml").split("<version>"),".[1]").split("</version>"), ".[0]")jq(entity.parents().map((parentEntity) => parentEntity.parents.map((parentEntity) => parentEntity.name)), ".[0]")okta.profileMappings.readokta.users.read
Obtain your Okta domain.
This can be found in the prefix of your Okta URL. For example, https://domain.okta.com.
Domain: Enter your Okta domain.
API token: Enter your Okta API token.
Group types: Specify which group types to include.
Click Save.
type
Type of embed (in this case, grafana)
✓
url
Embed URL for the Grafana dashboard
✓
Account alias: Enter your account alias.
API key: Enter your Coralogix API key.
Region: Select your region.
Click Save.
Tenant endpoint: Enter your tenant endpoint. This can be found in your Instana app URL.
API token: Enter the API token you generated in Instana.
Click Save.
Before getting started:
Create a Jenkins API key.
Note: This is only necessary if you plan to use Jenkins blocks in Cortex Workflows.
This integration uses the Cortex Deployer app, an open-source app that makes it easier for teams to push information about deploys to Cortex. This app leverages Cortex's .
Install the Cortex Deployer app.
To use the Cortex Deployer app, you will need the x-cortex-tag and a Cortex API token. In the example below, both are defined as Jenkins secrets.
To push information to Cortex about a deploy event, add a step to your Jenkins pipeline. Below is a snippet of what a Jenkinsfile may look like.
For more details about the options passed to the Docker image, please refer to the Deployer repository.
If you plan to use Jenkins blocks in Cortex Workflows, you will need to configure Jenkins in your Cortex workspace:
In Cortex, navigate to the Jenkins settings page:
Click Integrations from the main nav. Search for and select Jenkins.
Click +Add configuration.
Configure the integration form:
Alias: Enter an alias for the integration.
Username: Enter your Jenkins username.
API key: Enter your Jenkins API key.
Host: Enter the base URL of your Jenkins instance.
Click Save.
After you configure the integration, you will see data about Jenkins deploys in an entity's details page:
On the entity overview, Jenkins deploys will appear under the Latest events section.
In the entity's sidebar, click Events to see a full list of events for the entity, including deploy events from Jenkins.
In the entity's sidebar, click CI/CD > Deploys to see data from the , including Jenkins deploys.
You can use a Workflow to kick off a Jenkins pipeline. See this docs page for more information.
Since the Jenkins integration uses Cortex's , Jenkins data is included in Eng Intelligence deploy metrics. Learn more about Eng Intelligence in the docs.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Before getting started:
Generate an access key in Sumo Logic.
Determine your assigned deployment in Sumo Logic.
In Cortex, navigate to the Sumo Logic settings page:
Click Integrations from the main nav. Search for and select Sumo Logic.
Click Add configuration.
Configure the Sumo Logic integration form:
Access ID: Enter the access ID for Sumo Logic.
Access key: Enter the access key you generated in Sumo Logic.
Deployment: Enter your Sumo Logic deployment.
Click Save.
You can create and manage SLOs by listing SLO IDs in the entity descriptor:
When an SLO is defined in an entity's descriptor, you'll see an overview of SLO information in the Monitoring block on an entity details page overview.
On the left side of an entity, click Monitoring > Sumo Logic to view the SLO query, target(s), current value for each SLO, a graph of SLO performance over time, and the period of time the SLO is being calculated for. For example, if the time listed is "7 days ago," then the SLO is looking at the time range starting 7 days ago to now.
With the Sumo Logic integration, you can create Scorecard rules and write CQL queries based on Sumo Logic SLOs.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Before getting started, create a BambooHR API key.
In Cortex, navigate to the BambooHR settings page.
Click Integrations from the main nav. Search for and select BambooHR.
Click Add configuration.
Configure the BambooHR integration form:
Subdomain: Enter your BambooHR subdomain.
This can be found in your app URL, e.g., subdomain.bamboohr.com.
API token: Enter your BambooHR API token.
Report ID: Optionally, enter a Report ID to filter the list of employees.
Click Save.
See the Create teams documentation for instructions on importing entities.
Ownership of each catalog entity through BambooHR is defined through an owner of type group.
The name should be exactly equal to the value in the Team field.
With the BambooHR integration, you can create Scorecard rules and write CQL queries based on BambooHR teams.
See more examples in the CQL Explorer in Cortex.
Cortex conducts an ownership sync for BambooHR teams every day at 6 a.m. UTC.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Data models are foundational, but configurable.
Integrations are available, but extensible.
Experience is complete, but customizable.
With consistent developer workflow and a configurable experience, it's easier to accurately represent your services and infrastructure in Cortex. See an overview of Cortex data concepts below.
Need assistance with data modeling? To ensure a smooth implementation, most of our customers partner with Cortex Professional Services (PS) for hands-on assistance, including expert guidance on data modeling. Contact [email protected] to learn more.
The pages in this section cover the following topics:
How to import and manage entities
An entity is an object that represents a software construct. Entities are represented in YAML and can pull in data from integrations. Entities can have dependencies, can be set up in a hierarchical structure, and can be connected to other entities through entity relationships. Entity standards can be ensured through Scorecards. Learn more in Managing entities.
How to create and manage catalogs
Catalogs are a defined selection of entities. You can use them to track and store information about all the components that make up your infrastructure. Learn more in .
Integrations
Cortex supports pulling data across a broad set of integrations to create a single pane of glass. See all integrations in the sub-pages under .
Want to learn more? Check out the Cortex Academy course on Catalogs, Entities, and Relationships, available to all Cortex customers and POVs.
Learn about the basic data concepts for Cortex below.
Team
A group of humans responsible for something
Service
A running technical component (API, job, infra service)
Domain
A foundational grouping layer that represents a logical or functional area of your organization. The bone structure of your Cortex model. Domains form the base hierarchy that organizes entities (services, systems, pipelines) under stable, high-level boundaries. Each domain reflects a cohesive area of ownership, business function, or technical responsibility.
Custom entity
Any other trackable thing - ML models, Clients, environment, release, Products. Use this when "service" doesn't fit.
Catalog
A folder-like visual container, for UI organization only
Group
A logical collection for search, filtering, and reporting. Similar to a label or tag set.
Before getting started:
Create a CircleCI API token.
Self-hosted CircleCI instances
If you’re using a self-hosted instance of CircleCI, you’ll need to verify that your Cortex instance is able to reach the CircleCI instance. We route our requests through a static IP address. Reach out to support at [email protected] to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your CircleCI instance.
In Cortex, navigate to the CircleCI settings page.
Click Integrations from the main nav. Search for and select CircleCI.
Click Add configuration.
Configure the integration form:
Account alias: Enter an alias for this integration, used to tie entity registrations to different configurations.
API token: Enter the value of the API token you created in CircleCI.
Host: Enter the URL for your CircleCI instance if self-hosted, e.g., https://cortex.circleci.com
Click Save.
Configure the integration for multiple CircleCI accounts
The CircleCI integration has multi-account support. You can add a configuration for each additional by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the CircleCI page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
You can define CircleCI projects in an entity's YAML descriptor. Add its project slug under the x-cortex-circle-ci block:
When an entity has a CircleCI project defined in its YAML file, you will see metric and pipeline details on an entity's details page. Click CI/CD > CircleCI in the entity's sidebar to see this information.
With the CircleCI integration, you can create Scorecard rules and write CQL queries based on CircleCI metrics and pipelines.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Learn more: Review and evaluate a Scorecard.
Take action
Last, you take action: Prioritize what to fix, set deadlines with Initiatives, and continue your Scorecard practices to ensure ongoing improvement.
Learn more: Take action on a Scorecard.
In a Scorecard, entities are scored against rules. Rules can reference entities' metadata within Cortex, and can pull data from third-party integrations. Use levels and points in Scorecards to gamify the process and encourage developers to make progress toward goals.
While Scorecards do encourage teams to standardize entities, they do not have deadlines attached; if you have a goal that is more urgent or has a specific deadline, you can create an Initiative to promote progress by a certain date.
See Scorecard examples for common use cases and to see how others are motivating their teams with Scorecards.
Looking to dive deeper? Check out the Cortex Academy course on Scorecards, available to all Cortex customers and POVs.
In the video below, learn how Scorecards, Initiatives, and Reports can be used together to drive business goals.
You can configure Scorecards directly in the Cortex UI, without needing to manage them solely through code. This makes it easier to get started, iterate over time, and involve more teammates without requiring deep context. If you prefer a GitOps approach, that's supported as well. See Scorecards as code for more information.
On this page, learn about viewing and editing Scorecards. For step by step instructions on creating Scorecards, see Creating a Scorecard. To learn about evaluating a Scorecard and mitigating failed rules, see Review and evaluate Scorecards.
Expand the tiles below to learn about viewing and editing Scorecards.
Admins can configure settings and view Scorecard rule exemptions under Settings > Scorecards.
See Scorecard settings for more information.
Cortex offers a wide variety of out-of-the-box integrations compatible with Scorecard rules. Sometimes, a Scorecard may have multiple integration queries with different endpoints, each with its own rate limits. While we strive to manage these rate limits efficiently, please keep the following points in mind regarding rule failures and third-party integrations:
Yes, any errors will be displayed alongside the rule for the relevant entity in the UI.
If we encounter a rate limit error, we will retry the rule for most integrations. This process occurs up to five times with a backoff period between attempts. If the rule fails after five retries, the last recorded score will be used.
If all retries are still affected by rate limit errors, we will use the last known score for the rule. This also applies to 5xx errors from upstream APIs and any unexpected errors from the Cortex side. If a new rule fails without a previous score, the rule will fail and display a 429 error.

Azure Resources provides on-demand cloud computing platforms and APIs. Cortex uses the Azure Resource API to pull in resource details and import entities such as SQL servers, virtual machines, virtual networks, load balancers, and others.
Integrating Azure Resources with Cortex allows you to:
Automatically import entities and track ownership of entities
Create Scorecards to drive alignment and track progress on projects involving resources from Azure
Before getting started, you will need the following information. These can be found in the Enterprise applications section of Azure:
Azure tenant ID
Azure client ID and
Azure subscription ID
Ensure that the service principal for the subscription ID has a .
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Azure Resources.
Click Add configuration.
Configure the Azure Resources integration form:
After saving your configuration, you are redirected to the integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Azure Resources was configured properly.
You can configure automatic import from Azure:
In Cortex, navigate to the .
Next to Auto import from AWS, Azure, and/or Google Cloud, click the toggle to enable the import.\
Cortex can automatically discover ownership for your Azure resources. To configure this:
Make sure that your Azure resources have a tag matching the x-cortex-tag of the corresponding Cortex team
Enable the “Sync ownership from Azure” toggle in the in Cortex.
By default, Cortex looks for the owner tag. You can also customize the tag key name on the Settings page.
Cortex syncs ownership from Azure Resources every day at 6 a.m. UTC.
Cortex automatically discovers dependencies between your services and resources by scanning for resources with specific Azure Resources tags. By default, a service will have dependencies on any Cortex resource that has a corresponding Azure Resources resource with Azure Resources tag key = "service" and tag value = the service's Cortex tag.
On the , you can customize the tag key names for dependencies.
For more information on defining dependencies, please see the .
See the for instructions on importing entities.
You can associate a Cortex entity with one or more Azure Resources entities. Cortex will display those Azure Resources entities' metadata on the Cortex entity page.
When the entity is connected to Azure, the entity YAML will look like the following:
With the Azure Resources integration, you can create Scorecard rules and write CQL queries based on Azure Resources details.
See more examples in the in Cortex.
Cortex conducts a background sync of Azure Resources every day at 10 a.m. UTC and an ownership sync every day at 6 a.m. UTC.
Why is the Azure resource type microsoft-resources-subscriptions-resourcegroups not pulling in Azure Resource details?
Cortex pulls from the Azure Resource API, but not from the Azure Resource Group API. If you would like to submit a feature request for support of Azure Resource Groups, please contact our customer engineering team.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Codecov is a code coverage reporting platform that that monitors how much of your code has been tested and validated. Codecov analytics can be used to drive visibility into your microservice architecture and understand coverage trends over time.
Integrating Cortex with Codecov allows you to:
View code coverage details for entities directly in Cortex
Create Scorecards that track progress and drive alignment on projects involving your Codecov code coverage metrics
Before getting started:
Create a .
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Codecov.
Click Add configuration.
Configure the Codecov integration form:
Cortex will use the GitHub, GitLab, Bitbucket, or Azure DevOps repository as the "best guess" for the corresponding Codecov project, since Codecov projects are connected to repositories. For example, if the GitHub repo associated with your Codecov instance is my-org/repo, then the entities in Cortex should also be associated with my-org/repo.
You can find the repository for a given entity in its YAML, defined in a block like the one below:
If the Codecov project you want to associate isn't the same as the repository, you can override this in the Cortex entity descriptor.
While Cortex uses the for discovery with many integrations, the repository is used for Codecov projects.
The value for repo should be the full repository because Codecov maps projects by repo.
Flags
Codecov's are used to categorize coverage reports for various features and tests in a given project. Flags allow you to set different statistics for different areas of your code base. For example, if you have a monorepo with multiple unique projects, you can use Codecov flags to evaluate each project with different test coverage metrics.
To pull flags into Cortex, define the flag line in the .
If you choose to configure with flags, discovery will be disabled; you would need to define the owner, repo, and provider lines.
With the Codecov integration, you can find code coverage details on an entity's details page as long as that entity is associated with a repo linked to your Codecov instance.
Click Code & security in the entity's sidebar to see the code coverage for that entity.
With the Codecov integration, you can create Scorecard rules and write CQL queries based on Codecov code coverage metrics.
See more examples in the in Cortex.
Setting up a rule based on code coverage can serve as a secondary check to confirm an entity is synced with Codecov and reporting frequently.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
In some instances, a Scorecard rule might not apply to an entity. For example, a rule may be linked to an Initiative your team is actively working on and the failure notification may be irrelevant or noisy to developers. Or, in rarer cases, the Scorecard rule may not make sense for a given component, depending on the nature of that entity. In either case, rule exemptions allow you to filter out components that shouldn’t be evaluated by a specific rule.
With rule exemptions, entities are not marked as passing or failing — the rule simply does not apply to those entities. If you use point-based rules instead of levels, the exempted rule will not be included in the average for a component’s percentage score. If you use levels, an exempt rule allows an entity to progress to the next level.
Any user can request a rule exemption, and Admins or users with the Configure Scorecard exemptions permission can approve, deny or revoke a rule exemption. Users with the View Scorecard exemptions permission can view exemptions in Scorecards that have been requested by any user; without that permission, a user can only see their own requested exemptions.
See our knowledge base for best practices on managing rule exemptions.
Any user can request an exemption. This can be done , or via the Cortex UI.
While viewing a Scorecard in the Cortex UI:
Click into an entity on which you want to request a rule exemption.
A side panel will open, showing each rule applied to that entity.
Next to the rule you want to request an exemption for, click the 3 dots icon, then click Request exemption.\
If the Scorecard has the enabled, then the exemption will automatically be approved.
If the Scorecard has user-specific notifications enabled, you'll need to select a user to notify of the rule exemption request. That user will be able to review, and approve or reject the request. If this field is not enabled, then all Admins will be notified of the request.
You’ll use a permanent exemption when there’s no expectation an entity will pass a rule, whereas a time-bound exemption makes more sense when an entity is expected to be in compliance with a given rule by a certain time.
In many cases, a time-bound exemption will be related to an ongoing Initiative. For example, entities might be required to have an on-call rotation set up by the end of the quarter. In this case, a developer may request an exemption that ends a few weeks before the quarter concludes — this can serve as a backup reminder if on-call isn’t set up at that point, and in the meantime, the failing rule won’t add any noise to the developer’s workflow.
When the time period for a temporary exemption elapses, any entities that are not in compliance with the rule would display as failing, while those in compliance would display as passing.
To approve or deny rule exemptions, you must be an Admin, or you must have a custom role that contains the Configure Scorecard exemptions .
Admins are able to , in addition to .
If your to enable auto-approval for exemptions, then you do not need to take any action to approve the exemption.
After the user submits an exemption request, the exemption will appear in the Scorecard's Exemptions tab as Exempt, with the option to revoke the exemption appearing on the right side of the rule:
Also note that if you are an admin user and you request an exemption, it will automatically approve.
If you have for rule exemption requests, then you will receive a notification when a user requests an exemption. The notification includes the name of the requestor, the rule name and its Scorecard, the entity that the exemption applies to, the reason and timeframe provided by the requestor, and a direct link to approve or deny the request in Cortex.
If you do not have notifications enabled, you can (in Scorecard's Exemptions tab or under Settings > Scorecards > Rule exemptions) and then accept, reject, or revoke from there.
You can , , or a Scorecard rule exemption via the API.
Admins, or users with the Configure Scorecard exemptions , can view exemption requests, approve or deny the request, and revoke exemptions.
When viewing a Scorecard, click into the Exemptions tab to view requests for exemptions and rules that have already been exempted:
In , admins can view a list of all requested exemptions:
Learn about CQL basics and CQL tools (Query builder and CQL explorer) in Cortex Query Language (CQL).
The Query builder allows you to define your query without needing to learn CQL upfront.
You will need the Run query builder permission. If you are running queries on third-party integrations, you will also need the Run query builder with third-party integrations permission.
On the right side of the Query builder page, click the CQL builder tab. \
In the CQL builder, choose and integration and a rule to evaluate.
The rules available in the dropdown menu will depend on the integration you've selected.
Under the CQL text editor on the left, select an entity to test the query against.
Click Test.
The results appear under the text editor. Review the results to verify that the query is working as you expect. \
In the lower right corner of the page, click Run query.
In the side panel that opens, choose whether to run the query on all entities or select specific entities.
At the bottom of the side panel, click Run query.
In the confirmation modal that appears, click Yes, run query.
After running the query, the page displays a list of all entities matching the criteria. In the upper right corner of the list, you can sort and filter the list. As you apply filters to your list, Cortex will also update the number of matching entities, so you can easily see at a glance how many entities match your requirements.
You can share the results in two ways:
Send a link: Click Share in the upper right corner of the results list to copy the URL to your clipboard. You can share the link with anyone who has access in your Cortex workspace.
Export as CSV: In the upper right corner of the page, click Export CSV to download a CSV file of the data.
If you want to run a query on more than one rule, you can join multiple queries together with AND and OR.
For example:
The following errors may occur when running a CQL query:
400: This typically indicates a misconfiguration with an integration. For example, you may be missing an entity registration required for an integration.
403: This occurs if there are missing or improper .
429: This occurs when hitting the rate limit for an integration. Cortex will retry 5 times before responding with this error. To prevent rate limit issues, we have built a self-throttling system that proactively throttles before hitting a rate limit from the vendor.
While viewing the results of a query you ran, you can save the query to use again in the future:
In the upper right corner of the results page, click Save query.\
In the side panel, configure the query details:
Enter a name and description for your query.
Below the CQL search text box, you can see active queries. This section displays the ongoing process of your submitted query. When the query is complete, it will appear under Recent.
Along the top of the query builder, you can click into tabs to view Saved and Recent queries. Click into any of the queries in these lists to view the results of the query.
Click the Saved tab to view a list of your saved queries, and queries that others have saved and shared across your organization.
Query results are not automatically updated, but you can refresh a query manually: While viewing the results page, click the 3 dots icon, then click Refresh.
When configuring a , it is possible to enable automatic refresh.
Click the Recent tab. This list shows all queries that have been run in the last 30 days.
LaunchDarkly is a feature flag management platform.
Integrating Cortex with LaunchDarkly allows you to:
Track LaunchDarkly feature flags on entities in the catalog.
Create Scorecards that track progress and drive alignment on projects involving your LaunchDarkly feature flags.
Perform tasks relating to LaunchDarkly feature flags as a part of a Workflow.
For example, you can include a "Create feature flag" step within a Workflow.
Before getting started, create a with:
The Writer role
If you are not adding LaunchDarkly-related tasks to your , you can configure the token with the Reader role.
20220603 as the API version
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select LaunchDarkly.
Click Add configuration.
Configure the integration details:
The LaunchDarkly integration has multi-account support. You can add a configuration for each additional organization, instance, or account by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated organization, instance, or account with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the LaunchDarkly page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
By default, Cortex will try to "best-guess" the corresponding project in LaunchDarkly based on the key or tags.
Cortex first looks up a LaunchDarkly project using the entity name (e.g. My Service), then the entity identifier (e.g. my-service). For example, if your entity name is “My Service”, then the corresponding LaunchDarkly project's key or tag should contain either “My Service” or "my-service".
If no project was matched, Cortex will try to "best-guess" feature flags from all available projects using feature flag tags.
You can find the project key and tags in LaunchDarkly under Account settings > Projects. The URL for the project will contain the key. For example: https://app.launchdarkly.com/projects/default/settings/environments.
If you prefer to use the project tags in the registration instead, you can find it in the projects table or project settings page.
With the LaunchDarkly integration, you can create Scorecard rules and write CQL queries based on LaunchDarkly projects.
See more examples in the in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
CQL reports are ideal when you need to extract, analyze, or share detailed data that goes beyond pass/fail checks, and when you want to create reusable, auto-refreshing reports for ongoing visibility. They allow you to query and visualize raw data from your entities via CQL with more flexibility than what Scorecards or Query Builder provide:
View any expression result, such as the exact number of incidents, deployment counts, or custom data values for each entity
Scorecards and Query Builder require expressions to evaluate to a boolean.
that aggregate and display data from entity metadata, integrations and custom data
by surfacing the underlying data that drives rule outcomes
Export filtered data for further analysis or sharing
You will need the Run query builder permission. If you are running queries on third-party integrations, you will also need the Run query builder with third-party integrations permission.
In the main nav of Cortex, click Tools > CQL reports. In the upper right corner of the page, click Create CQL report.
Choose whether to start from scratch or use a template.
If you opt to work from a template, you’ll be able to select from any of your organization’s available templates — along with templates built into Cortex — making it easier to ensure all best practices are being followed.
Note that if the return value is too large (like a 5 MB JSON file) the cell in the report results will error out, so we recommend defining raw values for outputs. The maximum data size that can be the value of a cell is 2048 bytes.
You can view previously created CQL reports at Tools > CQL reports. Click into a report name to view its results.
You can sort by each column of the report, select which columns are displayed, and filter by AWS account, AWS region, domain, entity, entity type, group, owner, or team.
By default the report displays all entities. Click the Mine tab to view information for only your owned entities.
You may need to share a CQL report with teams or leaders to provide detailed, custom insights into entity data, compliance, or operational metrics. Click Export CSV in the upper right corner of the report to generate a CSV file.
A report must be set to Public in order to share it.
Cortex does not automatically refresh a CQL report. If you did not configure auto refresh for the report, you can refresh it manually: While viewing the results page, click the 3 dots icon, then click Refresh CQL report.
If a report contains expressions written using an outdated version of CQL, you will see a warning banner at the top of the page stating that the report cannot be refreshed. After you update any outdated CQL queries, you will be able to refresh the report.
While , you can schedule an auto refresh. By default, auto refresh is disabled.
If you didn't add auto refresh when creating the CQL report, you can also edit the report later on to enable the setting.
With auto refresh enabled, in the upper right corner of a CQL report page, you will see the last refresh time and the next scheduled evaluation:
To edit an existing CQL report:
Navigate to Tools > CQL Reports. Click the CQL report you want to edit.
In the upper right corner of the CQL report, click Edit.
Make any necessary changes, then at the bottom of the page, click Save.
You can use CQL reports to help interpret unexpected results from Scorecards.
For example, let's say you have a service that is failing the rule Readme created. However, you believe the service does have a readme file, and you aren't sure why it's failing this rule.
We could create a CQL report from scratch and add a new column for the README CQL expression to check for README.md in the git repo:
After saving the CQL report, you can view the results to see the contents of readme files for each entity. In this report, you will be able to see if the readme contains an error such as "The result is too large to store," which would explain why the entity is failing that rule in the Scorecard.
Rollbar is an error tracking tool that helps developers discover and resolve crashes and errors.
Integrating Rollbar with Cortex allows you to:
View errors on entity pages in Cortex, giving you insight into your entity's operational maturity
Create Scorecards that include rules relating to error data from Rollbar, motivating team members to improve their code quality
Before getting started:
Create a .
The token requires read permissions at minimum. This allows Cortex to automatically look up project tokens for each Rollbar project and attempt to reuse them to access project details.
Granting the token read and write permissions enables Cortex to automatically create an access token if none exists for a given project.
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select Rollbar.
Click Add configuration.
Configure the integration form:
After saving your configuration, you are redirected to the Rollbar integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Rollbar was configured properly.
By default, Cortex will use the (e.g. my-entity) as the "best guess" for Rollbar projects. For example, if your Cortex tag is my-entity, then the corresponding project in Rollbar should also be my-entity.
If your Rollbar projects don’t cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
You can define projects under the x-cortex-rollbar block in an :
Error data from Rollbar will appear on an . In an entity's sidebar, click Error tracking to view detected issues for each Rollbar project. At the top of the page, see the associated project tag and the project framework.
Under Items, see a list of detected errors and their statuses. Next to the error name, you can also see badges for # seen and the type of event: error, warning, or info.
With the Rollbar integration, you can create Scorecard rules and write CQL queries based on Rollbar projects.
See more examples in the in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Apiiro is an application security posture management (ASPM) platform that helps you understand and manage application security risks.
Integrating Apiiro with Cortex allows you to:
View risks on entity pages in Cortex, quickly connecting issues to entities and their owners
Use Scorecards to drive quality improvements to your security practices relating to Apiiro applications, and set Initiatives to prioritize tasks and set deadlines.
Before getting started:
Create an . Include the following permissions:
Risks > Read
Inventory management > Applications > Read
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Apiiro.
Click Add configuration.
Configure the integration form:
After saving your configuration, you are redirected to the Apiiro integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Apiiro was configured properly.
Cortex uses the entity name, , or repository as the "best guess" for the corresponding Apiiro application. For example, if your entity name is "My Service" or your tag is my-service, then the corresponding application name in Apiiro should also be My Service or my-service.
If your Apiiro application names don’t cleanly match the Cortex entity name or tag, you can override this in the Cortex entity descriptor.
You can define repositories and applications in the under the x-cortex-apiiro block:
On an overview, see risks listed under the Code & security block. Within this block, issues and vulnerabilities are grouped by severity: Critical, High, Medium, and Low. Click into any of these to open a list of all applicable issues and vulnerabilities.
In an entity's sidebar, click Code & security > Apiiro to view risks from Apiiro.
With the Apiiro integration, you can create Scorecard rules and write CQL queries based on Apiiro risks.
See more examples in the in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Checkmarx is an automated application security platform that checks source code for security vulnerabilities and compliance issues. Integrate Cortex with Checkmarx to drive insight into the vulnerabilities detected on your entities.
This integration is supported for Checkmarx Static Application Security Testing (SAST).
Before getting started, create a user with access to the sast_rest_api scope.
If you're using a self-hosted instance of Checkmarx, you'll need to verify that your Cortex instance is able to reach the Checkmarx instance. We route our requests through a static IP address. Reach out to support at to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your Checkmarx instance.
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Checkmarx.
Click Add configuration.
Configure the Checkmarx integration form:
By default, Cortex will use your associated Git repository (e.g. repo-name) or the service tag as the "best guess" for the Checkmarx project name.
If your repository and entity names don’t cleanly match the Checkmarx CxSAST project names, or if you have multiple Checkmarx projects for a service, you can add a Checkmarx project ID (recommended) or a Checkmarx project name in the Cortex entity descriptor.
We recommend using the project ID as it is a unique identifier across projects.
Example using project IDs:
Example using both project IDs and names:
Once the integration is established, vulnerabilities pulled from Checkmarx will be available for each entity in the Code and Security block in the Overview tab.
While viewing an entity, click Code & security > Checkmarx. On this page, view the number of vulnerabilities per severity and a link directly to your Checkmarx instance.
With the Checkmarx integration, you can create Scorecard rules and write CQL queries based on Checkmarx details.
See more examples in the in Cortex.
Does Cortex support integrating with Checkmarx One?
No, Cortex does not currently support Checkmarx one. Only Checkmarx SAST is supported for this integration.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
The teams getting the most value from the MCP have developed prompt patterns that fit naturally into their workflows. We've collated the most effective prompt patterns we've seen across different roles and workflows to build the list of prompt examples below. Think of it as a starting point for building your own prompt library, one that fits the specific needs of your team and organization.
The best prompts for engineers eliminate context switching at the moments when focus matters most.
is a declarative, GitOps continuous delivery tool for Kubernetes.
Integrating Cortex with ArgoCD allows you to:
Send information about ArgoCD syncs into Cortex
This data appears on .
Use
is an application monitoring platform that helps developers identify, debug, and resolve issues.
Integrating Sentry with Cortex allows you to:
, giving you insight into your entity's operational maturity
, using the Cortex Slack Bot
Create that include rules related to Sentry errors
is an automated security platform that identifies and remediates vulnerabilities in software applications. DAST, SAST, and SCA are supported.
Integrating Veracode with Cortex allows you to:
in Cortex
Create that track progress and drive alignment on Veracode vulnerability metrics
Splunk On-Call (formerly known as ) is an alert and on-call management platform.
Integrating Cortex with Splunk On-Call allows you to:
Pull in on-call rotation data and escalation policies
The on-call user or team will appear in the Current On-call block on an entity's details page.
The Scorecard use cases and examples this is section are based on engineering teams across a wide spectrum of sizes and maturity levels. Learn and what look like.
See additional detailed examples in the :
Custom webhook integrations allow you to POST data to a unique endpoint in Cortex, map the payload to existing entities, and make that data available for use in , , and on .
Using a custom webhook is especially helpful if:
You have internal tools, homegrown systems, or third-party services that Cortex doesn't integrate with yet.
You want to automate the process of sending custom metrics, events, or other data into Cortex without building and maintaining additional infrastructure.
, formerly known as Azure Active Directory, is an identity service that provides SSO and authentication.
Integrating Cortex with Entra ID allows you to:
Automatically discover and track Entra ID teams and team memberships
Track ownership of entities
Create that track progress and drive alignment on projects involving your Entra ID teams
is an application stability monitoring platform that provides error tracking and analytics.
Integrating BugSnag with Cortex allows you to:
in Cortex, giving you insight into your entity's operational maturity
Create that include rules related to BugSnag errors
is static application security testing (SAST) tool that includes software composition analysis (SCA). It detects security vulnerabilities in your code and analyzes your open-source dependencies for vulnerabilities. You can use it to scan local repositories or integrate it into your CI/CD pipeline.
Integrating Semgrep with Cortex allows you to:
Display the latest scans and vulnerability data
Create that track progress and drive alignment on projects involving Semgrep security data, allowing you to address and remediate vulnerabilities more efficiently
Splunk Observability Cloud () is a monitoring and analytics platform that allows customers to evaluate, visualize, automate, and alert on metrics.
Integrating Splunk Observability Cloud with Cortex allows you to:
in Cortex
Create that include rules related to your Splunk Observability Cloud SLOs
x-cortex-owners:
- type: group
name: Engineering # group name in Okta
provider: OKTA
description: This is a description for this owner # optionalownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)ownership.teams().all(team => team.description != null and team.isArchived == false)x-cortex-dashboards:
embeds:
- type: grafana
url: https://snapshots.raintank.io/dashboard-solo/snapshot/y7zwi2bZ7FcoTlB93WN7yWO4aMiz3pZb?from=1493369923321&to=1493377123321&panelId=4&orgId=0embeds().any((embed) => embed.type == "GRAFANA")info:
x-cortex-coralogix:
applications:
- applicationName: my-app # application name tied to alert
alias: my-alias # alias is optional and only relevant if you have opted into multi account supportcoralogix != nullccoralogix.alerts().length >= 3coralogix.alerts(statuses = ["triggered"]).length -= 0pipeline {
agent any
environment
stages {
stage('update-cortex') {
steps {
sh "docker run cortexapp/deployer:0.2 -i \"Jenkins deploy\" -k $CORTEX_API_TOKEN -s $GIT_COMMIT -t DEPLOY -e Prod -c '' -g $CORTEX_TAG"
}
}
}
}slos().all((slo) => slo.passing) == trueslos().filter((slo) => slo.name.matchesIn("latency") and slo.sliValue >= 0.9999).length > 0x-cortex-slos:
sumologic:
- id: 000000000001234
- id: 000000000006789ownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)ownership.teams().all(team => team.description != null and team.isArchived == false)x-cortex-owners:
- type: group
name: My Bamboo HR Team
provider: BAMBOO_HR
description: This is a description for this owner # optionalcircleci.flakyTests().length == 0circleci.projects().all((project) => project.metrics.successRate > 0.9) == truex-cortex-circle-ci:
projects:
- projectSlug: circleci-projectslug # projectslug in CircleCI
alias: circleci-alias # alias is optional and only relevant if you have opted into multi account supportx-cortex-groups:
- tier0
- language:kotlinTell me about the [service-name] service, including who owns it, what it does, and where the documentation lives.
This query pulls everything from your Cortex catalog at once. You get ownership, a description of what the service does, links to documentation, and the team's communication channels. Instead of hunting across wikis, Slack, and GitHub, you have the context you need to start working.
Show me the dependencies for [service-name]. Which services does it depend on, and which services depend on it?
Understanding the dependency graph is critical when planning changes with potential downstream impact. This prompt reveals what might break and which teams need to be in the conversation before you make a move.
Which Scorecard is [service-name] failing, and what do I need to fix? This prompt transforms maintenance from reactive to proactive. Instead of waiting for your platform team to flag issues or discovering gaps during an incident, you see exactly which Scorecards are failing and what specific checks need attention. You can address production readiness, security, or documentation gaps on your own schedule, before they become blockers.
The best prompts for engineering leaders are about trends, patterns, and the health of systems; these prompts surface the signals that inform strategic decisions.
The best prompts for platform teams show you where adoption is working, where it's stalled, and which teams need support.
The best prompts for SRE teams focus on proactive incident prevention or responding quickly to a incident in progress.
The best prompts for security engineers help them monitor, audit, and enforce security posture across services.
The best prompts for product managers focus on visibility, delivery health, and compliance to engineering standards that affect product velocity and quality.
Dependency
One entity relies on another. Enables impact analysis and notifications.
Ownership
Accountability link between a team and entity.
Entity relationship
Generic link between entities
Hierarchy
Parent-child or part-of structure. Enables inheritance ownership.
We recommend entering a Report ID if you have a custom BambooHR Report that has the authoritative list of active employees.
This value can be found in the app URL, e.g., subdomain.bamboohr.comreports/custom/New+Hires/REPORTID
Employee ownership field: Optionally, enter the ownership field name.
If left blank, Cortex defaults to finding the list of employees using their division followed by their department.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Account alias: Enter your Azure account alias. Account aliases are used to tie service registrations to different configuration accounts.
Azure tenant ID: Enter your Azure tenant ID.
Client ID and Client secret: Enter your Azure client ID and secret.
Subscription ID: Enter your Azure subscription ID.
Click Save.
You will be redirected to the Azure Resources Settings page in Cortex, where you can optionally choose to include only specified Azure resource types for this integration. You can also enable automatic import for any discovered entities of known types.

On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
API token: Enter your Codecov access token.
Host: If you're using a custom Codecov instance, enter your host URL.
Make sure to enter the URL without the API path (e.g., https://codecov.getcortexapp.com).
Click Save.
owner
Name of the Git organization
✓
repo
Git repository (without the organization)
✓
provider
One of the Git providers in the sample YAML
✓
flag
Pulls from isolated and categorized coverage reports
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
We recommend including a reason when you submit an exemption request. Requests will be reviewed by admins, and a clear explanation will help them determine whether an exemption makes sense.
Learn more about permanent vs. time-bound exemptions below.
Click Submit request.






Click Use query. The query will automatically populate into the CQL text editor on the left side of the page.\
500: This indicates that the integration itself returned an error.
Click Save.






Account alias: Enter the alias for this configuration.
Access token: Enter your LaunchDarkly access token.
Environment: Select your environment.
Click Save.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
CQL report name: Enter a name for the report.
Description: Enter a description for the report. This helps others in your workspace understand the purpose of the report.
Enable auto refresh: Enable this toggle setting if this report should be automatically evaluated on a specified interval.
Evaluation window: Set how often you want this report to be evaluated. The minimum refresh window is 12 hours, and the maximum is 336 hours (2 weeks).\
Apply to specific entities: Optionally narrow the scope of your report by selecting specific entities. If left blank, the report will apply to all entities.
Advanced options: You can further refine your selection by including or excluding groups. While adding a CQL expression, you can .
Note that you cannot query third-party integrations when refining the entity selection for a CQL report.
Columns:
Click Add column to start adding new CQL expressions to the report.
If you used a template, you can click the pencil icon next to an existing rule to edit it.
When adding or editing columns, you can write a CQL expression or use the form builder, which allows you to select rules from your configured integrations. To use the form builder, click the
When you are done adding columns, click Create at the bottom of the page.
If you want your report to be publicly available to other users in your workspace, enable the toggle next to Public.






Account access token: Enter the access token you generated in Rollbar.
Account name: Enter your Rollbar account name, found in your Rollbar settings.
The name also appears in the URL for your Rollbar instance, e.g.,
Click Save.
project
Project name as defined in Rollbar
✓
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Inventory management > Repositories > ReadAlias: Enter an alias for your configuration.
API key: Enter the API key you generated in Apiiro.
Host: Enter the base URL of your Apiiro instance. If left blank, the default host will be used.
Click Save.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Username and Password: Enter the username and password for the user with access to sast_rest_api.
Host: Enter the full URL of your Checkmarx instance.
Click Save.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
To send Cortex information about syncs in ArgoCD, use ArgoCD notification Webhooks to call the Cortex .
Here is an example of what a argocd-notifications-cm config map may look like:
This example assumes your ArgoCD application's name matches the x-cortex-tag. In this case, each application in ArgoCD can subscribe to the same trigger.
If your application name doesn't match the x-cortex-tag, add a value/pair to the info section of the Application manifest. Then, instead of using .app.metadata.name in the url, use .app.spec.info[0].value.
Next, subscribe your application to the webhook. You do this by adding a label annotation in the Application spec in the following format:
For example, if we want to subscribe an application to the example webhook above, the Application YAML may look like the following example:
After you configure the integration, you will see data about ArgoCD syncs in an entity's details page:
On the entity overview, ArgoCD syncs will appear under the Latest events section.\
In the entity's sidebar, click Events to see a full list of events for the entity, including sync events from ArgoCD.
In the entity's sidebar, click CI/CD > Deploys to see data from the , including ArgoCD syncs.\
You can use a Workflow to automate ArgoCD syncs. See this docs page for more information.
Since the ArgoCD integration uses Cortex's , ArgoCD data is included in Eng Intelligence deploy metrics. Learn more about Eng Intelligence in the docs.
The API key needs to be able to call the "Add deployment for entity" API endpoint, so ensure the Edit entities permission is enabled.
Make sure the encoded Cortex API Key does not contain an extra line. Use a tool like https://www.base64encode.org/ to ensure your encoded key does not contain an extra line.
The notification webhook is managed by the argocd-notifications-controller which will have a pod running in your ArgoCD namespace.
Assuming the ArgoCD is running in the argocd namepsace, run the following command to get the list of pods:
kubectl get pods -n argocd
This will return a list of pods similar to the ones listed below:
In this example, the pod managing the webhook notifications is argocd-notifications-controller-6cd988b564-sql55. To get the logs, run the following command:
kubectl logs argocd-notifications-controller-6cd988b564-sql55 -n argocd
If your trigger was successful, you should seem something similar to this:
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Before getting started:
Create a personal token in your Sentry user settings.
The token requires Read permissions for the Issue & Event and Project scopes.
In Cortex, navigate to the Sentry settings page:
Click Integrations from the main nav. Search for and select Sentry.
Click Add configuration.
Configure the integration form:
Auth token: Enter the personal token you generated in Sentry.
Organization slug: Enter your Sentry organization slug.
You can find this in your Sentry URL, e.g., https://sentry.io/organizations/{SLUG}/issues/.
Host
Click Save.
After saving your configuration, you are redirected to the Sentry integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Sentry was configured properly.
By default, Cortex will use the Cortex tag (e.g., my-entity) as the best guess for Sentry projects. For example, if your Cortex tag is my-entity, then the corresponding project in Sentry should also be my-entity.
If your Sentry projects don't cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
You can define projects under the x-cortex-sentry block:
name
Project ID or slug defined in Sentry.
Note that this is case sensitive.
✓
Error data will appear on an entity's details page. In an entity's sidebar, click Error tracking to view detected issues for each Sentry project. At the top of the page, see a list of Sentry projects associated with an entity. Each project listed in Cortex links back to the project details page in Sentry.
Under the Issues header on the Error tracking page, you'll find a list of all issues related to the projects that Cortex detected in Sentry. Each issue in the list links back to that issue's details page in Sentry. Cortex will pull in the title and tags for each issue.
Events
Sentry issues and events will also appear in an entity's event timeline, found under Events in the sidebar. This allows users to contextualize Sentry issues with other key data - like deploys or errors discovered from other integrations - during incidents or migrations.
If you have also configured the Slack integration, you can use the command /cortex sentry <tag> in Slack to get a list of all recent Sentry issues for a given entity. tag is the Cortex tag.
With the Sentry integration, you can create Scorecard rules and write CQL queries based on Sentry projects.
See more examples in the CQL Explorer in Cortex.
The maximum number of Sentry events fetched for any query is 1,000, while the maximum number of issues fetched is 300.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Before getting started:
Create an API ID in Veracode.
If using XML, configure the ID with the following permissions:
get Detailed report
get Build list
get sandbox list
get application list
If using REST, configure the ID with the following permissions:
get application
get findings
Create a with the following roles:
Creator or Security Lead
Reviewer or Security Lead
Results API
If you're using a self-hosted instance of Veracode, you'll need to verify that your Cortex instance is able to reach the Veracode instance. We route our requests through a static IP address. Reach out to support at [email protected] to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your Veracode instance.
In Cortex, navigate to the Veracode settings page:
Click Integrations from the main nav. Search for and select Veracode.
Click Add configuration.
Configure the Veracode integration form:
Key ID: Enter your Veracode API ID.
Secret key: Enter the secret key associated with your API ID.
Region: Enter your Veracode instance .
Click Save.
If you’re unable to expose your Veracode instance to be reachable by Cortex, you can set up a custom integration webhook.
You can set up the Veracode integration for an entity by specifying its Veracode application names or sandboxes in the x-cortex-static-analysis section of the entity descriptor. For example:
The application and sandbox names must appear exactly as they are in Veracode.
On an entity details page overview, Veracode findings will appear the Code and Security block.
When viewing an entity, click Code & security > Veracode to see the DAST findings count, SAST findings count, SCA findings count, and a list of findings that can be filtered by severity and source. The data syncs automatically every hour, or you can click Sync findings in the upper right side of the entity's Veracode page to trigger a sync.
With the Veracode integration, you can create Scorecard rules and write CQL queries based on Veracode findings.
See more examples in the CQL Explorer in Cortex.
Cortex conducts an entity sync for Veracode every hour.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Create Scorecards that track progress and drive alignment on projects involving Prometheus SLOs
There are two options for integrating Prometheus: the default configuration method and Cortex Axon Relay, a relay broker allows you to securely connect your on-premises Prometheus data.
Before getting started, set up basic authentication credentials in Prometheus.
Configure the integration in Cortex
In Cortex, navigate to the Prometheus settings page:
Click Integrations from the main nav. Search for and select Prometheus.
Click Add integration.
Configure the Prometheus integration form:
Account alias: Enter your account alias.
Username and Password: Enter your Prometheus basic auth credentials.
Host: Enter your self-managed Prometheus hostname.
Click Save.
Configure Prometheus with Cortex Axon Relay
See for instructions. Make sure to follow the Prometheus-specific instructions for the docker-compose.yml file.
Configure the integration for multiple Prometheus accounts
The Prometheus integration has multi-account support. You can add a configuration for each additional by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the Prometheus page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
You can create and manage SLOs by listing relevant SLIs through queries.
errorQuery
Query that indicates error events for your metric.
totalQuery
Query that indicates all events to be considered for your metric.
slo
Target number for SLO.
alias
Ties the SLO registration to a Prometheus instance listed under Settings → Prometheus. The alias parameter is optional, but if not provided the SLO will use the default configuration under Settings → Prometheus.
name
The SLO's name in Prometheus. The name parameter is optional.
When Cortex gets an SLO from Prometheus, the following query is calculated for it:
This value is calculated and resolved on an hour window, and calculated back for 7 days. Cortex averages the value for each 1-hour window, then averages each of those hourly averages across the lookback period, before displaying it in your Cortex workspace.
The value is updated when the entity page is loaded and when Scorecards are evaluated.
When an SLO is defined in an entity's descriptor, you'll see detailed data about SLOs in the Monitoring page in the sidebar of an entity details page. See the SLO query, target, the current value for each SLO, and the period of time the SLO is being calculated for. For example, if the time listed is "7 days ago," then the SLO is looking at the time range starting 7 days ago to now..
With the Prometheus integration, you can create Scorecard rules and write CQL queries based on Prometheus SLOs.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Create Scorecards that track progress and drive alignment on projects involving your on-call schedule
Before getting started:
Create a Splunk On-Call API key.
Note: If the key is granted Read-only permissions, Cortex will only perform GET requests.
Obtain your Splunk API ID.
In your Splunk On-Call portal, navigate to the Integrations page then click the API tab. Your API ID is displayed above your API keys.
In Cortex, navigate to the Splunk On-call settings page:
Click Integrations from the main nav. Search for and select Splunk On-call.
Click Add configuration.
Configure the VictorOps integration form:
API ID: Enter your API ID from Splunk On-Call.
API key: Enter your API key from Splunk On-Call.
Organization slug: Enter your Splunk On-Call organization slug.
This can be found at the end of the URL for your Splunk On-Call portal (e.g., https://portal.victorops.com/dash/
Click Save.
With the Splunk On-Call integration, you can tie on-call rotations to entities under the x-cortex-oncall block with your schedule metadata. You can use the team ID, or you can filter beyond the team ID and use the policy ID. Using the policy ID is helpful if your team has multiple policies available.
Team ID in entity descriptor:
Policy ID in entity descriptor:
type
Type of on-call data (in this case, SCHEDULE)
✓
id
ID for the team assigned to the given schedule
✓
You can find the team ID in the Splunk On-Call portal on the teams page (e.g., https://portal.victorops.com/dash/cortex-app#/team//users).
Once a Splunk On-Call schedule is defined in an entity descriptor, the user or team who is on call will appear in the Current On-call block on that entity's details page.
You can also find on-call information for a given entity on the On-call & incidents page in the entity's sidebar.
With the Splunk On-Call integration, you can create Scorecard rules and write CQL queries based on Splunk On-Call schedules.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Learn about Scorecard use cases in Cortex Academy
Learn more about leveraging Cortex to achieve operational readiness in the Cortex Academy course, "Cortex Solutions: Production Readiness"
Learn more about planning and managing migrations using Cortex in the Cortex Academy course, "Cortex Solutions: Migrations and Modernizations"
Scorecards are often aspirational. For example, an SRE team may define a Production Readiness Scorecard with 20+ criteria that they think their services should meet to be considered "ready" for SRE support.
The engineering team may not be resourced to actually meet those goals, but setting objective targets helps drive organization-wide cultural shifts and sets a baseline for conversations around tech debt, infrastructure investment, and service quality.
You can add as many levels as you want to a Scorecard. You can also add as many rules to each level as makes sense for the Scorecard, but keep in mind that an entity must pass all rules in a given level in order to progress to the next one.
When creating rules, we recommend starting with smaller, achievable goals within the Scorecard's first level. Early wins help teams build confidence and momentum. Introducing too many complex rules upfront can feel overwhelming and discouraging.
Focusing on clear, incremental improvements will create a culture of steady progress. Teams will see tangible improvements in reliability, documentation, or readiness without needing a massive investment of time. Once the basic benchmarks are in place and widely adopted, you can expand to more advanced rules, ensuring the process feels supportive and achievable rather than punitive.
Sometimes, an entity or team will fail a rule in a Scorecard. This gives you the opportunity to identify issues and take action on them, leading to incremental improvements over time. Learn more about evaluating Scorecards and remediating failed rules in Review and evaluate Scorecards.
Cortex users commonly define Scorecards across several categories:
Development Maturity: Ensure services and resources conform to basic development best practices, such as established code coverage, checking in lockfiles, READMEs, package versions, and ownership.
Operational Readiness: Determine whether services and resources are ready to be deployed to production, checking for runbooks, dashboards, logs, on-call escalation policies, monitoring/alerting, and accountable owners.
Operational Maturity: Monitor whether services are meeting SLOs, on-call metrics look healthy, and post-mortem tickets are closed promptly, gauging if there too many customer-facing incidents.
Security: Mitigate security vulnerabilities, achieve security compliance across services, measure code coverage
Best Practices: Define organization-wide best practices, such as infrastructure + platform, SRE, and security. For example, the Scorecard might help you ensure the correct platform library version is being used.
Best practices are unique to every organization and every application, so make sure to work across teams to develop a Scorecard measuring your organization's standards.
The following example uses JavaScript best practices:
This can be done without auth or an explicit Cortex tag in the URL if you do not have access to the Cortex tag or the ability to add authentication headers.
Below the instructions, see an example demonstrating how to send additional GitHub metadata into Cortex via webhook.
In Cortex, navigate to Integrations. On the left side of the Integrations page, click Custom integrations.
Click +Add custom integration.\
Configure the integration details:
Integration name: Enter a name for the integration.
Entity tag JQ: Enter the JQ that will be used to extract the entity's from the data. This tells Cortex where in the payload body we can find the Cortex tag.
For example, the payload shown in would have .data.codeTag as the JQ, and frontend-service would be the entity's Cortex tag.
If the tag Cortex extracts from the payload does not match an existing Cortex tag, it will result in a 400 error and the custom metadata will not be updated. Learn about .
Key: Enter the custom metadata key.
Data will be stored under the key for entities, similar to adding data via or .
In the , the key is mydata.
Click Save.
Copy the provided webhook URL.
Note that the entity must exist in Cortex before you send the payload.
cURL is a quick and flexible method to post to the webhook and verify that it's receiving data.
Save your payload as a .json file. Include the field that matches the JQ expression configured in the previous steps, so Cortex can map the data to the correct entity. For example, the payload might look like this:
In your terminal, use cURL to POST the JSON, using a command similar to the following:
curl -X POST -H "Content-Type: application/json" --data <path to json file> <webhook URL>
For example: curl -X POST -H "Content-Type: application/json" --data @/tmp/payload.json https://api.getcortexapp.com/api/v1/custom-integrations/data/12345abcdef
After sending data, the JSON payload is written to the entity's key that you configured for the custom webhook in Step 1.
If the webhook payload does not contain a value that maps to the exact Cortex tag, you can configure alternative mappings to look up when processing payloads. Use the x-cortex-custom-integration-mappings block in the entity descriptor YAML. For example:
When processing a payload, Cortex takes the output of the Entity tag JQ field in Step 1 above and searches for an entity with that value as a Cortex tag. If no such entity exists, Cortex checks whether an entity has registered the value as an alternative mapping; if so, the payload is attached to that entity.
Similar to when you add custom metadata to an entity, custom integration data appears in the sidebar on an entity details page within the Custom data & metrics page. It appears with an INTEGRATION tag next to the key name.
In this example, we create a webhook integration to send GitHub data into Cortex.
While Cortex does offer a native integration with GitHub, there may be scenarios where you want to send additional metadata that isn't included in the native integration.
Create a custom webhook integration in Cortex.
Enter a descriptive name so others understand the purpose of this webhook, such as "GitHub metadata."
In this example, we use the Service query .repository.name and the Key githubTest.
Copy the webhook URL generated in Cortex for this integration.
In GitHub, under Settings > Webhooks, create a webhook.
In the webhook's settings under Payload URL, paste in the webhook URL from Cortex.
Set the Content type to application/json.
Push a commit to your GitHub repository.
In your GitHub settings under Webhooks, click the Recent Deliveries tab to see the payload that will be sent. Because you set the JQ query to .repository.name, the repository name value in the payload will correspond with the Cortex tag in Cortex.
In the example screen shot, the repository name is "michigan":\
Navigate to the entity in Cortex.
In this example, the repository name is "michigan," so we can search in Cortex to find an entity with "michigan" as its Cortex tag.
On the , click Custom data & metrics from the entity's sidebar.
Next to the githubTest key, you will see the payload sent from GitHub:\
For information on configuring Entra ID SSO for logging in to Cortex, see the Microsoft Entra ID SSO documentation.
Follow Microsoft's documentation to register a new single tenant Entra ID application.
In your Entra ID admin center, navigate to your new application, and then to API Permissions. Add the following permissions:
Microsoft APIs > Microsoft Graph > Application permissions > User > User.Read.All
Microsoft APIs > Microsoft Graph > Application permissions > Group > Group.Read.All
Click Grant Admin Consent to grant permissions for all accounts in the directory.
Navigate to Certificates & secrets and click New client secret.
Note that you will need to rotate the secret before the expiration date you set for it.
Navigate to the application's Overview page and copy the client ID. You will need the client ID and secret in the next steps.
In Cortex, navigate to the Entra ID settings page.
Click Integrations from the main nav. Search for and select Entra ID.
Click Add configuration.
Configure the integration form:
Tenant ID: Enter your Entra ID .
Client ID and Client secret: Enter the client ID and secret you generated in the previous steps.
Click Save.
You will be redirected to the Azure Active Directory settings page in Cortex, where you can optionally set a group filter to limit which groups are pulled in from Entra ID.
See the Create services documentation for instructions on importing entities.
The group name is case-sensitive and should be exactly the same as in Entra ID.
Under Catalogs > Teams, you will see teams and team members pulled in from Entra ID.
If you have ownership of entities set up, then Azure AD teams and users will be listed in the Owners page for an entity.
With the Entra ID integration, you can create Scorecard rules and write CQL queries based on Entra ID teams.
See more examples in the CQL Explorer in Cortex.
Cortex conducts an ownership sync every day at 6 a.m. UTC.
Why were all my Entra ID users unexpectedly deleted after rotating my client secret?
Updating your configuration can cause a temporary deletion of users. When you delete the old secret from your Azure AD configuration in Cortex, a sync is triggered to delete the users. The addition of the new secret to your configuration will trigger a sync to add the users. There may be a delay before seeing the users re-added.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Before getting started:
Create a BugSnag auth token in your BugSnag account's settings page under "My account."
You must have the Configure integrations permission in Cortex.
If you're using a self-hosted instance of BugSnag, you'll need to verify that your Cortex instance is able to reach the BugSnag instance. We route our requests through a static IP address. Reach out to support at [email protected] to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your BugSnag instance.
In Cortex, navigate to the BugSnag settings page.
Click Integrations from the main nav. Search for and select BugSnag.
Click Add configuration.
Configure the integration form:
Auth token: Enter the auth token you generated in BugSnag.
Organization slug: Enter your BugSnag organization slug.
You can find this in your BugSnag URL, e.g., https://app.bugsnag.com/organizations/{SLUG}/stability-center.
Click Save.
After saving your configuration, you are redirected to the BugSnag integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure BugSnag was configured properly.
By default, Cortex will use the Cortex tag (e.g. my-entity) as the "best guess" for BugSnag projects. For example, if your Cortex tag is my-entity, then the corresponding project in BugSnag should also be my-entity.
If your BugSnag projects don’t cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
You can define projects under the x-cortex-bugsnag block:
project
Project key defined in BugSnag
✓
Error data will appear on an entity's details page. You can find the total number of detected errors and a full list on the Error tracking page in the entity's side panel. Error data is fetched live.
Each error in the list will display with an Error, Info, or Warning tag based on the severity applied to a given error in BugSnag.
With the BugSnag integration, you can create Scorecard rules and write CQL queries based on BugSnag projects and issues.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Before getting started:
Create an API token in Semgrep with GET scan details and GET List code or supply chain findings permissions.
In Cortex, navigate to the Semgrep settings page:
Click Integrations from the main nav. Search for and select Semgrep.
Click Add configuration.
Configure the Semgrep integration form:
Alias: Enter an alias for this integration.
API key: Enter the value of the API token you created in Semgrep.
Organization ID: Enter your organization ID for Semgrep.
Organization slug: Enter your organization slug for Semgrep.
Click Save.
After saving your configuration, you are redirected to the Semgrep integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Semgrep was configured properly.
By default, Cortex will use the Cortex tag (e.g. my-service) as the "best guess" for Semgrep projects. For example, if your entity name is "My Service" or your tag is my-service, then the corresponding project name in Semgrep should also be "My Service" or my-service.
If your Semgrep project names don’t cleanly match the Cortex entity name or tag, you can override this in the Cortex entity descriptor.
Under the x-cortex-semgrep block in an entity's YAML, you can define the projects you want based on the Semgrep project ID. For example:
Semgrap vulnerabilities and scans appear on entity details pages:
in the Code & security block in the entity's overview:\
in the entity's sidebar in Code & security.
This page contains scan results and vulnerability metrics from Semgrep. Click Filter at the top of the vulnerability list to filter by severity.
With the Semgrep integration, you can create Scorecard rules and write CQL queries based on Semgrep projects.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Before getting started:
Create an access token in Splunk.
In Cortex, navigate to the Splunk Observability settings page:
Click Integrations from the main nav. Search for and select Splunk Observability.
Click Add configuration.
Configure the integration form:
Realm: Enter your Splunk Observability realm.
You can find it in the URL for your instance, e.g., https://app.{REALM}.signalfx.com/#/metrics.
Access token: Enter the access token you generated in Splunk.
Click Save.
After saving your configuration, you are redirected to the Splunk Observability integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Splunk Observability was configured properly.
SLOs can be defined in the entity descriptor.
You can pull in data about SLOs and manage them in Cortex by defining relevant SLIs through queries, along with a threshold and a comparator. Cortex will pull data from Splunk Observability Cloud and roll up the query with a specified rollup function.
query
for your metric: Use sf_metric to filter by the given metric and add additional dimensions to narrow the searchQueries resulting in multiple datasets will be rolled up according to rollup
✓
rollup
SUM or AVERAGE
✓
target
Target number for the SLO
✓
lookback
(P[n]Y[n]M[n]DT[n]H[n]M[n]S)
✓
When an SLO is defined in an entity's descriptor, SLO information appears in the Monitoring block on an entity details page's overview.
Monitoring
Click Monitoring > Data overview in the entity's sidebar to see the query, target, and current value for each SLO from any integrations you're pulling SLOs from. Each SLO also includes the period of time the SLO is being calculated for. For example, if the time listed is "7 days ago," then the SLO is looking at the time range starting 7 days ago to now.\
Click Monitoring > Splunk Observability to view a graph of SLO performance over time.\
With the Splunk Observability Cloud integration, you can create Scorecard rules and write CQL queries based on Splunk Observability Cloud SLOs.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .



Cortex MCP is a Model Context Protocol server that provides access to the Cortex API. It uses relevant context from your workspace, ensuring awareness of your system's structure when answering your questions.
You can query information in natural language, powering faster decisions and efficient processes. For example:
Who is the right person to handle an incident with backend-server?
Show me the services that belong to the platform engineering team
Show me the currently active Scorecards and how example-entity is performing. Give me ideas on how I can improve them
We're having an incident with backend-server, give me a summary of information to help handle the incident
What's going on with my Git migration Scorecard?
I want to run an initiative to migrate our company to using GitHub actions. Help me figure out how to do this in Cortex
As someone on the security team, is there anything I should be worried about in my org?
Learn about and see below.
Use Cortex MCP with Devin Cortex MCP is . Cortex MCP identifies the work that needs to be done, and Devin autonomously performs the work — creating PRs, updating documentation, and refactoring code — to bring your services into compliance. .
See a demonstration of how you can use Cortex MCP to get quick answers without having to switch tools:
You can host the MCP server locally, or you can use a remote implementation.
Before getting started:
in Cortex.
You should have an MCP-compatible client installed, such as , , or .
Paid subscriptions to MCP clients generally give you a larger context window, but the free versions of these clients should suffice.
If hosting the MCP server locally, you should also have
Step 1: Install Cortex MCP
Run the following command:
Step 2: Configure your MCP client
Update your MCP client's configuration file. Make sure to include your Cortex access token value for the CORTEX_API_TOKEN argument:
Alternate option: Create and configure the file in terminal
After updating your configuration, restart your MCP client.
If you are a , you must also set CORTEX_API_BASE_URL=https:// alongside the CORTEX_API_TOKEN variable.
In your MCP client, ask a question about your Cortex workspace. The client will use the to provide detailed answers based on your data.
For example:
You might ask what's going on with a specific Scorecard. The MCP client will respond with an overview, Scorecard structure information, a progress summary, and suggestions for next steps.
You could ask about the custom data that an entity has. The MCP client will respond with that entity's custom data and information about when it was created:
You could ask about the dependencies an entity has. The MCP client will respond with a list of incoming and outgoing dependencies:
Cortex MCP can use the following endpoints:
Additional tools:
getMyWorkspace: this tool supports the "Mine" capabilities that are available in the Cortex UI. With this tool, you can ask questions like, "Show me my Cortex entities" or "Tell me how my entities are performing against the Production Readiness Scorecard." This tool is enabled by default.
metrics are also available to Cortex MCP as part of the AI Chief of Staff feature. This brings metric data directly into the Cortex MCP, enabling richer AI-assisted insights, not only into engineering performance, but across your entire Cortex ecosystem. It allows you to be a more proactive leader and enables more data-driven planning sessions.
To query Eng Intelligence metrics in MCP:
Ensure you have the latest Cortex MCP version configured in your environment. Once enabled, the MCP will automatically include endpoints for Eng Intelligence metrics. You can then query Eng Intelligence metrics alongside ownership, Scorecard, and Initiative information. For example:
Evaluate my DORA metric performance in Q3. Highlight where the team is performing well and bring areas of improvement to my attention
Which services have concerning MTTR trends, and what scorecard gaps are contributing?
Recommend initiatives and scorecard changes I could consider to address my upward trend in incidents
Review last quarter’s performance against our goals, identify the top three bottlenecks, and suggest changes to our scorecards to address them
Learn how the AI Chief of Staff helps leaders move from viewing data to acting on it:
Before submitting questions or commands, you may want to limit the number of provided tools being used by the MCP provider. For example, you might only want to use the MCP to ask about entities but you do not want to allow questions about Scorecards.
In the settings of your MCP client, it is possible to limit which Cortex tools are being used.
The Cortex MCP becomes more powerful when using it becomes second nature to your teams. That shift happens when you have developed prompts that fit your specific role, answer your recurring questions, and surface information in the exact moments you need it. Follow these best practices when crafting prompts:
Be specific: Instead of "tell me about services," you could say, "Show me all critical services failing the Production Readiness Scorecard." This will give you more actionable information.
Combine multiple questions when context helps: The MCP handles complex prompts like "Who owns orders-api, when was it last deployed, and are there any open incidents?" You get richer context in response to one question instead of piecing together three separate queries.
Reference your organization's specific constructs: If you've defined custom Scorecards or Initiatives in Cortex, reference them by name. The MCP understands your organization's specific standards and can query against them directly.
We've collated the most effective prompt patterns we've seen across different roles and workflows to build out a library of prompts for engineers, engineering leaders, platform engineers, and SREs. See for the full list of prompts.
For more information, see the .
See the beta pages to learn more about the , which enables the use of Engineering Intelligence metrics in MCP (now available in research preview).
We'd love your feedback! If you've been using the Cortex MCP, we'd love to hear your direct feedback on the configuration process, the tools available, and how you've been using it. Your feedback helps us improve and expand our capabilities, if you are interested in helping guide our MCP direction, please submit the survey .
This can happen if you are on the free plan of your MCP client.
No, you cannot make changes or write data via the Cortex MCP. The MCP is strictly read-only—it only handles GET requests and cannot modify or write data.
Ensure that the value of your Cortex API token is valid in your configuration.
Ensure that your OpenAPI spec path is correct when mounting.
Verify that your Cortex API endpoint is accessible.
Check that you are setting up the remote MCP with a generated in Cortex. Remote MCP setup requires a PAT, not an API key.
This is most likely caused by an issue within your network. We recommend contacting your organization's infrastructure or security team to troubleshoot.
Services are a default entity type in Cortex, used for entities such as microservices, libraries, components, etc – essentially any codebase-like module.
To view services, click Catalogs > Services from the main nav.
When you open the Services page, you'll see tabs labeled Mine and All, which denote services you own and all services visible to you in your Cortex workspace.
At the top of your services list, you can choose how the list is displayed:
Name: Click Name, then choose whether to sort by name or identifier (), and whether the sort order should be ascending or descending.
Display: Click Display, then choose whether to display hierarchies, whether to show archived, and which columns to display.
Filter: To narrow the scope of your list, click Filter then select criteria you'd like to filter by.
You can create services:
By importing them from a connected integration
Manually in the Cortex UI
Via the entity descriptor YAML through
Via the
You can import services directly from third-party integrations:
In Cortex, navigate to Catalogs > All entities, then click Import entities.
Choose Import discovered entities.
Select the integration to import from.
It is possible to edit entities after creating them:
Navigate to the entity's page.
In the upper right corner, click Configure entity.
Make any desired changes.
Note: The only field you cannot edit is the identifier.
ServiceNow is a CMDB (configuration management database) to define, manage, automate and structure IT services. Cortex integrates with ServiceNow to provide engineers with better developer experience while adhering to governance standards. The integration syncs data between systems so both stay current.
Integrating your ServiceNow instance with Cortex allows you to:
Import teams from ServiceNow and track ownership of entities
Automatically import domains and domain relationships from ServiceNow
to trigger ServiceNow actions, create tickets, or update records.
to view ServiceNow incidents directly on entity details pages.
Create that track progress and drive alignment on projects involving your ServiceNow teams
Some Cortex users link business applications to ServiceNow projects, creating a clear map of ownership and project alignment. This enables visibility into which projects tie to which business apps, helping track migrations, risk programs, and compliance projects.
Your ServiceNow user must have the sn_cmdb_user permission enabled.
You must have the Configure Integrations in Cortex.
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select ServiceNow.
Click Add configuration.
Configure the ServiceNow integration form:
Stay on this page for the next steps.
On the ServiceNow integrations settings page, click Add table mapping on the right.
Configure the "Add table mapping" form:
Choose a mapping type: Select whether your data will map to a Service, Team, Team members, Team & Team member relationships, Domain, or Domain relationships.
Table name
To import entities from ServiceNow, follow the steps described below.
See the documentation on:
You can .
You must have the Configure Settings permission.
Enabling automated domain import ensures that your domain structure in Cortex stays up-to-date with your ServiceNow configuration.
In Cortex, go to
Toggle the setting on to enable the automated import of any domains and domain relationships from ServiceNow.
The automatic sync runs daily at 2 p.m. UTC.
You must have the Enable Relationship graph permission.
To force a sync of newly-discovered domains:
Go to and select Domains.
Click the 3 dots icon in the upper right, then click Sync.
When an entity is connected to ServiceNow, the entity YAML will look like the following:
To import teams, to pull teams, team members, and their relationships from ServiceNow. After doing so, .
When an entity is owned by a ServiceNow team, the YAML will look like the following:
The value for name should be the name of the team as defined in ServiceNow (case-sensitive).
Learn more about ownership in .
With the ServiceNow integration, you can create Scorecard rules and write CQL queries based on ownership and team details.
See more examples in the in Cortex.
After integrating, you can set up to trigger actions in ServiceNow. See an example of this in Guides > Create ServiceNow incident.
You can install a plugin that makes ServiceNow incidents more visible on your entity details pages:
Learn more about installing the plugin in . You must have the Edit Plugins permission.
Cortex conducts a background sync of ServiceNow domains, domain relationships, and services every day at 2 p.m. UTC.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
A catalog is a defined selection of entities. You can use catalogs to track and store information about all of the components that make up your infrastructure. This includes everything from services and domains to AWS S3 buckets and RDS, Google Cloud resources, or Azure Resources.
While entities are defined by YAML files, catalogs themselves are not defined by a YAML file and must be created in the Cortex UI. Think of catalogs as a folder containing a collection of entities, with each entity defined by its own YAML file. An entity can belong to multiple catalogs, so you can also think of a catalog as a filter that defines which entity types to group together.
In the example screen shot below, the Services page contains a list of all entities that belong to the Service catalog:
Want to learn more? Check out the Cortex Academy course on Catalogs, available to all Cortex customers and POVs.
In the video below, see an overview of how Cortex helps you build a unified developer portal and catalog that improves visibility, adoption, and productivity:
By default, Cortex comes with four built-in catalogs:
Services contains all .
Infrastructure contains all entities representing your infrastructure assets.
Cortex pulls in resources directly from , , or , as their corresponding types out of the box. These resources are automatically added to the Infrastructure catalog.
You can choose to rename these catalogs to fit your own taxonomy, but note that the custom names of these default catalogs will not override the references to their default names throughout the app. Instead, you could choose to create additional custom catalogs.
To customize your Cortex instance to your organization's needs, you can also define custom catalogs in Cortex to represent your infrastructure. See below.
There are two types of catalogs:
Entity type catalogs
Define entity inclusion criteria through filters for entity type, tags, or groups.
For example, the built-in "service" catalog is configured to include entities of type service.
Click Catalogs from the main nav to view your list of catalogs. You must have the View catalogs permission.
When you click into a catalog, you can view all of the entities that belong to that catalog:
If a catalog can be configured with a hierarchy (such as domains, teams, or custom catalogs based on ), you can choose what is displayed in the list view:
At the top of the list, click Display.
Configure the display options:
To include the hierarchy in the list view, enable the toggle next to Display hierarchy.
To include entities that are not connected to any other entities, enable the toggle next to Show empty
The "All entities" page includes entities across all catalogs and entities of all types, whether the entity is one of the or whether it is a . To access this page, go to Catalogs > All Entities.
To view all entity types, go to Catalogs > All Entities then click the .
Learn more about entities in .
On the , you’ll find all pre-defined and custom catalogs in Cortex.
This page will reflect the same list of catalogs you find in the Catalogs dropdown menu in the main nav.
Just like "All entities", "All catalogs" includes a search bar and a sort function, as well as a toggle for displaying or hiding Drafts.
From this page, you can create new catalogs and edit existing ones.
You can create catalogs in the Cortex UI. For each catalog, you set the criteria that determines which entities belong to that catalog. In addition, you can define custom entity types to categorize the entities that live in your catalogs.
Because catalogs are not defined by a YAML file, it is not possible to create them via a GitOps workflow.
To create, edit, and delete catalogs, you must have the Edit catalogs permission.
To create a new catalog:
At the top of the "All catalogs" page, click Create catalog.
Configure the "Create catalog" form:
Name: Enter a name for the catalog.
Description: Optionally, enter a description of the catalog.
Once the catalog is created, you’ll find it under Catalogs > All catalogs, automatically populated with all entities that apply based on the entity types you've created. Catalogs with a relationship type filter can be displayed as a hierarchy.
You can edit a catalog's name, description, URL, display icon, and catalog filter type.
To edit a catalog:
In Cortex, go to Catalogs > All catalogs. Click into the catalog you want to edit, then click Edit catalog at the top of the page.
This will bring you back to the catalog creation page, with all the details from your last save.
Make any changes necessary to the catalog.
At the bottom of the page, click
You can use the to track changes made to any of your catalogs. Catalog updates will be listed as CATALOG in the Type column, and the updated catalog will be listed under the Entity column.
The Action column will indicate whether a catalog was created, deleted, or updated.
After an entity is imported or created, it will automatically belong to a catalog based on the entity type criteria set for each catalog. When you , you can set the entity type criteria.
For the default catalogs, the entity type criteria is set by default:
The Services catalog contains service entity types
The Domains catalog contains domain entity types
The Teams catalog contains team entity types
You must have the Configure appearance settings permission to configure the catalog display.
By default, catalogs will appear in alphabetical order, but you can manually adjust the order that the catalogs appear in the main nav.
Navigate to to drag and drop catalogs into your preferred order:
Cortex Workflows can trigger Terraform execution to manage your cloud infrastructure, such as provisioning new services, databases, buckets, or networking primitives.
Terraform is an infrastructure-as-code tool that lets you provision, manage, and update infrastructure. Terraform can help you manage databases, s3 buckets, clusters, and every other component that comprises your infra. Terraform’s ability to manage resources comes from providers, which are plugins that enable interaction with cloud providers, SaaS providers, and other APIs. Providers allow you to define as code what a resource looks like.
The instructions on this page apply to Terraform Cloud, the web-based interface for Terraform.
See end-to-end examples for , , and .
Expand the tile below for instructions on provisioning a new instance.
In Terraform Cloud, navigate to the Run page. Verify that the changes you made to the instance name in variables.tf have applied.
In Terraform, there are two primary commands: plan and apply.
The plan command creates a plan and preview of the changes that will be made to your infrastructure. During the plan stage, Terraform assesses the main.tf file with variables and compares it against the state. If there are differences, Terraform prompts you to approve and apply the change.
When you navigate to the run that was triggered by updating variables.tf, you can see that the plan was automatically conducted. In this case, the plan was to create an instance with the name provided earlier. Verify that the run displays a "Plan finished" message.
In AWS, you can confirm that the instance exists and that the Terraform action was successful:
Cortex not only integrates with Terraform, but can enhance your use of it. Once the integration is set up, you’ll use a to interact with Terraform.
You must have the Configure Scaffolder templates permission.
Create a JSON file that is equivalent to your Terraform module.
In this file, we defined the region and instance name. You’ll then update the fields in the variables.tf file so it knows to pull information from the Cookiecutter JSON.
in Cortex.
Terraform Cloud also has an API that can be used to make updates without following the pull request workflow. You can use a in Cortex to execute a run through the API. If a run is set to automatically apply, then Cortex will handle the rest of the process.
in Cortex.
Add a block.
Define inputs for Instance name, Region, and Instance type.
When the Workflow is run in Cortex, it will override data in the variables.tf file with information that was entered in the fields.
See guides on creating the following Workflows: , , and .
Wiz is a security platform that allows teams to find and fix issues in their code. Cortex integrates with Wiz to bring cloud and container vulnerabilities into your catalog.
Integrating Wiz with Cortex allows you to:
Automatically map projects to entities, eliminating the overhead of manually maintaining project-to-entity relationships
View Wiz issues directly on entity pages in Cortex
Leverage Wiz scanning capabilities earlier in the development lifecycle and enable visibility into security issues
Create that track progress and drive alignment on projects involving Wiz projects and issues
Before getting started:
.
Obtain your .
If you have IP restrictions in place in Wiz, to ensure that Cortex is allowed to make requests to Wiz.
Contact the Cortex Customer Engineering team for a list of IPs.
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select Wiz.
Click Add configuration.
Configure the Wiz integration form:
If you see a "No address associated with hostname" error, verify that you have entered the correct authentication provider.
By default, Cortex will use the (e.g. my-service) as the "best guess" for Wiz project. For example, if your entity name is "My Service" or your tag is my-service, then the corresponding project name in Wiz should also be My Service or my-service.
If your Wiz project names don’t cleanly match the Cortex entity name or tag, you can override this in the Cortex entity descriptor.
Expand the tile below to see how Cortex customers have modeled their data when mapping Wiz projects to entities.
Define the following block in your Cortex entity descriptor:
On an , you'll see Wiz issues, listed by risk level, under the Code and Security header.
In the entity's sidebar, click Code & Security > Wiz to view a list of Wiz issues including their severity, status, basic details, and a link to view the issue directly in Wiz:
With the Wiz integration, you can create Scorecard rules and write CQL queries based on Wiz projects.
See more examples in the in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
FireHydrant is an incident management platform that emphasizes reliability and consistency across the entire incident response lifecycle.
Integrating FireHydrant with Cortex allows you to:
View incidents on entity pages in Cortex, giving you insight into incidents to act on them quickly
Trigger new incidents directly from Cortex
Create Scorecards to set standards around incident management and production readiness
Before getting started:
Create a .
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select FireHydrant.
Click Add configuration.
Configure the integration:
You can define FireHydrant services in an .
For a given entity, define FireHydrant services by ID or slug. Each of these has the same field definitions.
You can find the service ID value in FireHydrant under FireHydrant > Catalog > Services. The URL for the service will also contain the ID (e.g., https://app.firehydrant.io/catalog/services/{ID}/incidents).
If you prefer to use the service slug in the registration instead, you can find it on the right-hand side of the service page in FireHydrant.
When active incidents are detected in FireHydrant, Cortex will display incident information on an .
Click On-call & incidents in the entity's sidebar to see all detected incidents.
Each issue will be listed with its title and description (when available). Cortex will also display the status for an issue as a badge next to its name:
Acknowledged
Closed
Detected
Identified
The issue's severity will also appear in a badge (e.g. SEV0, SEV1, SEV2).
While viewing an entity in Cortex, you can trigger an incident in FireHydrant:
In Cortex, navigate to an entity. On the left side of an entity details page, click On-call & incidents.
In the upper right side of the entity's "On-call" page, click Trigger incident.
Configure the incident modal:
Summary: Enter a title for the incident.
With the FireHydrant integration, you can create Scorecard rules and write CQL queries based on FireHydrant incidents.
See more examples in the in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Cortex Query Language (CQL) is a proprietary domain-specific language (DSL) you can use to query details in-depth about your Cortex entities. CQL is at the core of many Cortex features, from defining how Scorecards evaluate health and readiness to deciding which entities a plugin should appear on.
With CQL, you can:
Query your data immediately (including from third-party integrations or custom data), without having to move it, transform it, or wait for batch jobs
Cortex does not require you to configure custom processes for each new standard you want to track
You can , allowing you to do arbitrary JSON manipulations (e.g., fetch nested fields, group by, sum over, etc.). Cortex can transition seamlessly between CQL and JQ data types.
Use basic arithmetic and utility functions to get the data you need
Customize rules to query information needed to assess your processes quickly
For example, you can .
Create reusable to view any query result, such as the number of incidents your services had in the last week
CQL allows you to ask multi-source questions, such as, "Who's on call for services in our payment product?" or "Which services are still on the old secrets manager?"
It also provides a consistent way to write rules, regardless of the data source. For example, you can use git.fileExists() to search across all of your Git repositories without needing to specify the Git provider.
See additional CQL instructions and examples in the in your workspace.
CQL queries use the format data source function quantifier, with the function and quantifier options differing depending on the data source and type.
The data sources for CQL are:
Entity metadata: Core entity details
Example query: dependencies.in().length
Integrations: Data from
CQL expressions return different data types, and each type supports specific operations within queries. See the available data types and their supported operations in the .
You can combine CQL expressions in multiple ways:
Use AND to require multiple conditions to be true
Example: entity.type() == "container" AND entity.tag() == "production"
Use OR to allow for multiple possibilities
You can include entity or CQL evaluation data in a rule's description and failure message using captures. This will enable you to create a Scorecard rule description or failure message that reflects the rule’s score and affected entity descriptor information (including dependencies and custom data if set in the YAML). Captures allow you to update your rule expressions to “capture” certain pieces of an expression into variables.
Anywhere in Cortex where you use CQL, testing functionality allows you to quickly review and iterate on your queries. Below the CQL editor, select up to 10 entities to test against then click Test. Test results appear per entity below the editor.
You can test both boolean and non-boolean expressions anywhere in Cortex, but you can only save non-boolean expressions in .
The Query builder allows you to leverage all of CQL's power to investigate information about your entities without building an entire Scorecard.
The functionality of the Query builder depends on your . Users who have the ability to edit Scorecards can run queries that talk to third-party integrations. Users without those permissions can run queries on custom data and anything else that exists within Cortex. Users classified as viewers are not able to run queries.
To see the Query builder, click Tools > Query builder in the main nav.
Using custom data in CQL queries
You can add to any entity, and you can access custom data from any . For example, if you run a security scanning tool that isn't in the list of existing integrations, you may run a vulnerability scan as part of your CI process and then send that data to Cortex.
With the Query builder, you can query against any of this custom data. Anything that can be evaluated with a Scorecard will display in the Query builder, which allows you to essentially use Cortex as a database. Because Cortex is able to pull data from many data sources, the Query builder can even provide more insight than GitHub search.
contains instructions and examples for specific data types, entity metadata, custom data, and more.
You can access it via Query builder or as a standalone page:
On the Query builder page: On the right side of the Query builder, click the CQL explorer tab to view CQL instructions and examples for specific data types, entity metadata, custom data, and more.\
As a standalone page:
Click the flag icon on the right side of your Cortex workspace.\
CQL reports allow you to query all of the raw data in Cortex and build a custom report on the data. Learn more in .
To learn about running queries and saving queries, see .
Cortex is your source of truth to external docs. Instead of digging through wikis and other resources, you can aggregate docs on the relevant entities in Cortex in the following ways:
Cortex Axon is a framework that can be used to build jobs that run in your environment and securely send data to Cortex. It includes:
Custom handlers: It makes it easy to write code against the Cortex API that can send data to Cortex either on a regular interval, a cron schedule, or after processing a webhook.
See the for more information.
Internally-hosted integration support
is a continuous integration and delivery platform that enablers users to run fast, secure, and scalable pipelines on their own infrastructure.
Integrating Buildkite with Cortex allows you to:
Pull in metrics about your builds and pipelines
Create that track progress and drive alignment on projects involving your Buildkite pipelines
Domains offer a way to group entities into hierarchical units. You can group by product area, functionality, systems, business units, or something unique to your organization. With this feature, you can cluster entities into a single, hierarchical domain that can include both parents and children.
You can define a list of other entities as children for a domain, allowing you to represent a hierarchy of how your entities are modeled across your workspace. This hierarchy is available to view in the Domains catalog, on a domain entity's details page, and in the . The domain hierarchy can also be used to configure ownership inheritance, helping you keep track of ownership in case of personnel changes at your organization.
You can view all domains under Catalogs > Domains.
Spot problems early and drive action in Cortex
Eng Intelligence provides you with key metrics and high-level data to gain insights into services, bottlenecks in the pull request lifecycle, incident response, and more. These metrics can give context to cross-team activities and indicate areas that need deeper investigation, allowing you to quickly remediate and improve productivity across your teams.
Eng intelligence features include:
Dashboards:
The gives clear insights into how fast, reliable, and efficient your development practices are.
is an on-call management platform.
Integrating Cortex with xMatters allows you to:
Pull in on-call rotation data and escalation policies
The on-call user or team will appear in the Current On-call block on an entity's details page.
is an incident management and alerting platform.
Integrating incident.io with Cortex allows you to:
directly from Cortex
View incident data on entity pages in Cortex
Create that track progress and drive alignment on projects involving incidents
is an on-call and incident response platform.
Integrating Rootly with Cortex allows you to:
directly from Cortex
on entity pages in Cortex
When active incidents are detected in Rootly, Cortex will display incident information on an entity's details page in the
In Cortex, use the relationship graph to better understand:
Dependencies
Visualize how entities relate to one another
You can also from the Relationship Graph.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
x-cortex-azure:
ids:
- id: /subscriptions/1fbb2da1-2ce7-45e4-b85f-676ab8e685b9/resourceGroups/GROUP1/providers/Microsoft.Compute/disks/vm1_disk1_3d9f85717666435e9e87e4883d31a7e9
alias: my-default-alias # alias is optional and only relevant if you have opted into multi account support
- id: /subscriptions/1fbb2da1-2ce8-45e4-b85f-676ab8e685b0/resourceGroups/GROUP2/providers/Microsoft.Compute/disks/vm1_disk1_3d9f85717666435e9e87e4883d31a7e0
alias: my-other-alias # alias is optional and only relevant if you have opted into multi account supportazureResource.details() != nullazureResource.details().resources.filter((resource) => jq(resource, ".metadata.\"environment\"") != null).length > 0jq(azureResource.details(), ".resources[].metadata.siteConfig.healthCheckPath") != nullazureResource.details().resources.filter((resource) => resource.tags.get("tag-key") == "tag-value").length > 0x-cortex-git:
github:
repository: cortexapps/sample-repox-cortex-static-analysis:
codecov:
owner: org-name
repo: my-project
provider: AZURE_DEVOPS | BITBUCKET | BITBUCKET_SERVER | GITHUB | GITHUB_ENTERPRISE | GITLAB | GITLAB_ENTERPRISE
flag: flagcodecov.codeCoverage() >= 95git.commits().length == 2 AND azureDevops.workItems().length > 4x-cortex-launch-darkly:
projects:
- key: project-key
environments: # Optional
- environmentName: prod
- environmentName: staging
alias: alias-1 # alias is optional and only relevant if you have opted into multi account support
- tag: project-tag
environments: # Optional
- environmentName: prod
alias: alias-2 # alias is optional and only relevant if you have opted into multi account support
feature-flags:
- tag: feature-flag-tag
environments: # Optional
- environmentName: staging
alias: alias-3 # alias is optional and only relevant if you have opted into multi account supportlaunchDarkly != nulllaunchDarkly.flags().length < 10x-cortex-rollbar:
project: my-projectrollbar != nullrollbar == nullrollbar.rql("SELECT count(*) FROM item_occurrence WHERE status = 1") < 100rollbar.rql("SELECT count(*) / 30 FROM item_occurrence WHERE timestamp > unix_timestamp() - 60 * 60 * 24 * 30") < 5x-cortex-apiiro:
repositories:
- alias: alias-one
repositoryId: repository-one
- alias: alias-two
repositoryId: repository-two
applications:
- alias: alias-one
applicationId: application-one
- alias: alias-two
applicationId: application-twoapiiro.risks().length < 3apiiro != nullx-cortex-checkmarx:
projects:
- projectId: 1234
- projectId: 2345x-cortex-checkmarx:
projects:
- projectName: My Cool Project
- projectId: 1234checkmarx != nullcheckmarx.sastScanRisk() < 35checkmarx.numOfVulnerabilities(severity=["High"]) < 1checkmarx.numOfVulnerabilities() < 5apiVersion: v1
kind: ConfigMap
data:
context: |
argocdUrl: https://argo.company.com
service.webhook.cortex-webhook: |
url: https://api.getcortexapp.com
headers:
- name: Content-Type
value: application/json
- name: Accept
value: application/json
- name: Authorization
value: Bearer $token
subscriptions: |
- recipients:
- cortex-webhook
triggers:
- on-sync-succeeded
template.app-sync-succeeded: |
webhook:
cortex-webhook:
method: POST
path: /api/v1/catalog/{{.app.metadata.name}}/deploys
body: |
{ "customData": { "Sync Status": "{{.app.status.sync.status}}","Sync Details": "{{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true" },
"environment": "{{.app.spec.destination.name}}",
"sha": "{{.app.status.operationState.operation.sync.revision}}",
"timestamp": "{{.app.status.operationState.finishedAt}}",
"title": "Sync by ArgoCD",
"type": "DEPLOY"
}
trigger.on-sync-succeeded: |
- send:
- app-sync-succeeded
when: app.status.operationState.phase in ['Succeeded']
notifications.argoproj.io/subscribe.<trigger-name>.<webhook-name>: ""apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
annotations:
notifications.argoproj.io/subscribe.on-sync-succeeded.cortex-webhook: ""
...
NAME READY STATUS RESTARTS AGE
argocd-application-controller-0 1/1 Running 0 108d
argocd-applicationset-controller-69f96ccf5b-5jnpv 1/1 Running 0 108d
argocd-dex-server-5dff9c5998-j29zd 1/1 Running 0 80d
argocd-notifications-controller-6cd988b564-sql55 1/1 Running 0 107d
argocd-redis-54c687db9d-kdxwj 1/1 Running 0 80d
argocd-repo-server-6c6f8859c7-mrwll 1/1 Running 0 108d
argocd-server-b77b48886-s2mtg 1/1 Running 0 80dtime="2023-07-19T02:41:13Z" level=info msg="Start processing" app=argocd/app-direct
time="2023-07-19T02:41:13Z" level=info msg="Trigger on-sync-succeeded result: []" app=argocd/app-direct
time="2023-07-19T02:41:13Z" level=info msg="Notification about condition 'on-sync-succeeded.[0].zxM90Et6k4Elb1-fHdjtDJq0xR0' already sent to ''" app=argocd/app-direct
time="2023-07-19T02:41:13Z" level=info msg="Processing completed" app=argocd/app-directsentry != nullsentry.numOfIssueEvents("is:unresolved firstSeen:-1w") <= 10sentry.numOfIssues() < 100x-cortex-sentry:
projects:
- name: my-project
- name: my-second-projectveracode != nullveracode.findings(source = ["STATIC", "SCA"]).length < 10veracode.findings(risk = ["0", "2"]).length <= 3veracode.findings().filter((f) => f.findingStatus.status == "OPEN").length < 5x-cortex-static-analysis:
veracode:
applicationNames:
- My Application
- Second Application
sandboxes:
- applicationName: My Application
sandboxName: My Sandbox
- applicationName: Second Application
sandboxName: Second Sandboxslos().all((slo) => slo.passing) == trueslos().filter((slo) => slo.name.matchesIn("latency") and slo.sliValue >= 0.9999).length > 0x-cortex-slos:
prometheus:
- errorQuery: sum(rate(http_server_requests_seconds_count{code=~"(5..|429)"}[5m]))
totalQuery: sum(rate(http_server_requests_seconds_count[5m]))
slo: 99.95
alias: my-prometheus-instance # alias is optional and only relevant if you have opted into multi account support
name: my-slo-name(1 - ({errorQuery}) / ({totalQuery}))oncall != nulloncall.numOfEscalations() >= 2oncall.details().id == "sample-team1234"x-cortex-oncall:
victorops:
type: SCHEDULE
id: team-abcd12345x-cortex-oncall:
victorops:
type: SCHEDULE
id: team-abcd12345
policyIds:
- 12345
- 56789{
"data": {
"codeTag": "frontend-service",
"mydata": "4"
}
}x-cortex-custom-integration-mappings:
- frontend
- brain-serviceownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)x-cortex-owners:
- type: group
name: Engineering # group name in Entra ID
provider: ACTIVE_DIRECTORYbugsnag != nullbugsnag.numOfIssues() < 2bugsnag.numOfIssues("filters[error.status][][type]=example")x-cortex-bugsnag:
project: my-projectsemgrep != nullsemgrep.vulnerabilities().length < 10semgrep.scans().length < 10semgrep.scans("firstSeen:-1w") <= 10x-cortex-semgrep:
projects:
- alias: my_org
projectId: 1234567
- alias: other_org
projectId: 7654321slos().all((slo) => slo.passing) == trueslos().filter((slo) => slo.name.matchesIn("latency") and slo.sliValue >= 0.9999).length > 0x-cortex-slos:
signalfx:
- query: sf_metric:"jvm.memory.max" AND area:"nonheap"
rollup: AVERAGE
target: 5120000
lookback: P1Y
operation: "<="If you have multiple tenants, you can enter an ID here to monitor a specific tenant.
Client ID and Client secret: Enter the client ID and secret associated with the application link you created in the previous steps.
bugsnag.getcortexapp.com


operation
>, <, =, =
✓


bugsnag.getcortexapp.comAPI key: Enter the API key you created in FireHydrant.
Click Save.
Investigating
Mitigated
Postmortem completed
Postmortem started
Resolved
Started
Description: Enter a description of the incident.
Severity: Select a severity level.
Condition: Nature of the incident - Unavailable, Partially Unavailable, Degraded, Bug, or Operational.
At the bottom of the modal, click Trigger incident.
A confirmation screen will appear. In the confirmation, click the link to view the incident in FireHydrant.
Name
Severity
Status
Definition: firehydrant.incidents()
Examples
For a Scorecard focused on service maturity or quality, you can use this expression to make sure there are no detected or identified FireHydrant incidents with a severity rating of 1 for a given entity:
You can also tier severity-based rules to indicate progress over time. While the above rule might make sense in the first or second level, a higher-severity rule might make sense in a higher level:
identifier
Service ID or slug
✓
identifierType
Type of identifier (ID or SLUG)
✓
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
sentry.numOfIssues("is:unresolved environment:[production,prod] lastSeen:-1w") < 2x-cortex-firehydrant:
services:
- identifier: ASDF1234
identifierType: IDx-cortex-firehydrant:
services:
- identifier: service-slug
identifierType: SLUGfirehydrant != nullfirehydrant.incidents(severity = ["SEV1"], statuses = ["Detected", "Identified"]).length == 0firehydrant.incidents(severity = ["SEV3"], statuses = ["Detected", "Identified"]).length == 0When you are done adding a column, click Save column at the bottom of the side panel.

Benefits of using the remote MCP
The remote Cortex MCP uses the public cortex-mcp package as a dependency, installed from GitHub. This configuration of the Cortex MCP enables:
Faster setup: No need to install or maintain local binaries.
Updated context: Cortex automatically keeps the service aligned with the latest MCP specification.
Secure access: Tokens and access are managed in your Cortex workspace with security best practices.
Seamless integration: It works out of the box with popular MCP clients like VSCode, Claude Code, and Cursor.
More tools:
The remote MCP implementation includes more tools, such as the query_docs tool that allows you to query Cortex's documentation and knowledge base in natural language. Ask questions like “How do I configure PagerDuty for my Cortex services?” or "How can I use Cortex to drive AI maturity at my org?"
It also includes the ability to add private tools and integrations on top of the public functionality.
Step 1: Add the remote MCP server to your MCP client
Follow the instructions below for Claude, VSCode, or Cursor. Make sure to replace <CORTEX_TOKEN> with the value of the access token you generated in Cortex.
Claude Code
Run the following command to add the Cortex remote MCP server:
VSCode
Add the following configuration to your .vscode/mcp.json file:
For more information, see the .
Cursor
Add the following configuration to your Cursor settings:
Step 2: Validate your remote MCP configuration
Validate that your remote Cortex MCP is working.
VSCode:
Open the Command Palette and search for "MCP: List servers." Confirm that cortex appears as a connected server.
Claude:
Is there a correlation between my PR size and how fast we ship?
Restart Claude.
Navigate to your Claude chat and enter commands.
Use follow-up questions to drill down: Start broad, then go narrow. "Show me services with failing Scorecards" followed by "What specific checks is checkout-service failing?" moves you from landscape view to action items.
Build a library of your most-used prompts: If you ask the same question every Monday morning, save it. Some teams maintain shared prompt libraries so everyone can benefit from patterns that work. See the Cortex MCP Prompt Library below for ideas.


If you have a large volume of entites, click Filter in the upper right corner of the results list to select and apply entity type filters.
At the bottom of the page, click Next step.
Edit the details for the entity:
Type: Select Service.
Entity name: Enter a human readable name.
Identifier: This field is auto-populated based on your entity name. It is a unique identifier for your entity. This is also known as the x-cortex-tag.
Description: Enter a description of the entity to help others understand its purpose.
Groups: Select your entity.
Owners: Define for your entity. We recommend selecting team owners to keep your ownership information up-to-date through any future personnel changes.
You may see owners that Cortex . You can accept or reject the recommendations.
Links: Add links to external documentation, such as runbooks, docs, logs, or custom categories.
Parents: Define parent domains. This is where you configure the hierarchy for your entity. These can be visualized in the .
Dependencies: Select entities that this entity depends on. These can be visualized in the .
On-call: Configure on-call information.
Repository: Select the repository associated with this entity.
If you selected more than one entity: After the first entity is configured, click the name of the next entity on the right to navigate to the detail editor for that entity.
Click Confirm import.
To create a service:
In the main nav of Cortex, click Catalogs > Services.
At the top of the Services page, click +Import entities.
Choose Create entities manually.
Configure the form:
Type: Select Service.
Entity name: Enter a human readable name.
Identifier: This field is auto-populated based on your entity name. It is a unique identifier for your entity. This is also known as the x-cortex-tag.
When you are finished, click Confirm import at the bottom of the page.
Service entity descriptor
A barebones spec file has the OpenAPI version, along with an info section that contains some basic details.
Required fields
The only required fields under info are the title, x-cortex-tag, and x-cortex-type. The description is optional, but we highly recommend adding descriptions to all of your entities.
Example cortex.yaml for a service
You can create, update, and delete services using the .
At the bottom of the screen, click Save changes.



Instance name: Enter your instance identifier.
This can be found in your instance URL, e.g., <instance-identifier>.service-now.com.
Username and Password: Enter your ServiceNow username and password.
Click Save.
Table filter query: Optionally, enter a table filter query.
ID column name: Enter the column name that contains the ID of the record.
Name column name: Enter the column name that contains the name of the record.
Description column name: Enter the column name that contains the description of the record.
Note: To import teams, you must configure table mappings for the team, its team members, and their relationships.
Click Save table mapping.
Domain relationships cannot be manually imported; these are automatically imported via the automatic import setting described below.




On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
Teams contains all team entities and displays them in a hierarchical view alongside a leaderboard based on Scorecards.
This type enables grouping of entities based on a specific entity relationship type. These catalogs support visualizing hierarchical relationships. They support the ability to have different entity types relate to one another.
For example, the built-in "domain" catalog includes entities associated with each other via parent/child domain relationship. This catalog displays all entities that are a part of the domain hierarchy, including entity types that are not domains.
To include archived entities in the list view, enable the toggle next to Show archived.
Click Done.
Display icon: an icon to appear alongside the catalog throughout the app.
URL: Enter a unique URL slug.
By default, the URL slug will be generated based on the catalog’s name, but you can use the URL field to create a custom slug.
Catalog filter: In this section, you can define the entities that are included in your catalog. All entities that match the criteria defined in this section will be automatically included in the catalog. You can use one filter to define a catalog page — choose an entity type or a relationship type.
Option 1: Entity Type: Catalogs can include a combination of any entity types, or can include just one type.
Choose whether to include or exclude the entity types you select.
Optionally, under "Advanced options," enter a specific CQL expression to fine-tune your catalog based on specific criteria.
Option 2: Relationship Type: Catalogs can include one relationship type.\
Save as draft: Choose whether to save the catalog as a draft or publish it. Only admins and managers have the ability to view drafts.
Click Create.
The Infrastructure catalog contains any entities that are not the types service, domain, or team.
By default, any custom entity types you create will belong to the Infrastructure catalog. If you do not want the entity type to belong to this catalog, you can add the entity type to a different catalog.





Update the instance name in the Terraform variables.tf file.
All Terraform modules come with a file called variables.tf. As part of the Terraform script, we can enter variables for a given set, like region or instance type. In the example screen shot below, the variable name is "My Other Great Instance".
Note: Terraform modules also come with a main.tf file, which contains instructions and information about the action. In our example, the main.tf file describes the instance that we’re going to create through Terraform.
Run the Workflow. When you run it, Cortex will automatically open a pull request against the selected repository.
Add an HTTP request block. Configure the following fields:
HTTP method: Select POST.
URL: Enter the URL for the Terraform API you want to call.
Headers: Add Authorization: Bearer {{token}} and Content-type: application/(name).
Payload: Build the payload by referencing the outputs of the "User input" block, e.g., {{actions.input.outputs.instance-name}}
Save the Workflow. After saving, click Run at the top of the Workflow to run it.








Client ID and Client secret: Enter your client ID and client secret from Wiz.
Tenant region: Enter the region from Wiz.
Authentication provider: Select your authentication provider. You can confirm the provider in Wiz under User Settings > Tenant.
Click Save.
Entity tag: engineering-project
Wiz project name: Engineering project
Auto-mapping across multiple integrations
Some customers organize multiple integrations to use consistent names and tags across all of them.
For example:
Cortex domain entity name: Engineering project
Entity tag: engineering-project
Wiz project name: Engineering project
Jira project name: engineering-project
When you , Cortex will tie Jira tickets to entities by searching for any tickets where the label, component, or project field for the work item includes the Cortex tag.
Service-level auto-mapping based on repo structure
Some customers use a standardized repository naming convention that makes service-level auto-mapping simple and automated to the Wiz projects.
For example:
Repository name: engineering/integrations/eng-repo
Cortex domain entity name: Eng Repo
Entity tag in Cortex: eng-repo
Wiz project name: eng-repo

On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
jira.numOfIssues()Custom data: Data attached to the entity, or defined in the entity YAML
Example query: custom("cloud-cost") .cost.compute.actual
Example: entity.type() == "container" OR entity.type() == "function"
Combine AND and OR with parentheses
Example: (entity.type() == "container" OR entity.type() == "function") AND entity.tag() == "production"
Use ! to negate a condition
Example: !entity.tag() == "production"
In the Help & Docs side panel, click CQL explorer. \




If you have configured the Slack integration, you can use Slack Bot commands to list an entity's docs links directly in Slack.
Links appear on an entity details page in the Links & docs section:
On entities, you can add links to docs, runbooks, tech specs, dashboards, and more.
Before editing an entity via the UI, make sure that UI editing is enabled under Settings > GitOps.
In Cortex, navigate to an entity.
In the upper right corner of the entity details page, click Configure entity.
Click Links on the left side.
Click +Add.
Configure the link:
Type: Select the .
To create a new type, enter the type name then click the name in the dropdown.
Learn more about , , and types below.
Click Add.
In the entity descriptor, add a list of link objects:
name, type, and url are required.
The value of type can be defined based on your organization's preferences. Common examples include dashboard, documentation, healthcheck, logs, metrics, and runbook. See the sections below on this page describing , , and .
You can quickly look up links using the Cortex Slack Bot.
Cortex automatically embeds markdown files from the docs folder of your repo or from the root directory. If Cortex detects relevant files, these docs show up under the Links & docs page in an entity's sidebar.
Cortex uses the React markdown library for rendering the documents.
When adding links to an entity, Cortex supports embedding OpenAPI or AsyncAPI specs, embedding specs from your repository, adding relative links to a repository that isn't associated with the entity, and embedding charts (from Datadog, Grafana, New Relic, or other sources). You can also create a custom type while adding a link.
Cortex supports displaying Swagger/OpenAPI or AsyncAPI specs for each entity in the API explorer on an entity details page. You can also authorize your API and run queries directly in the API explorer.
You can use your entity descriptor file as an OpenAPI spec file. As mentioned in the documentation on entities, the entity descriptor file extends the OpenAPI spec, so you can implement the spec directly in this file.
You may have existing or external specs you want to display in the API explorer from sources such as Swagger Hub or GitHub Raw URL. Add these to the JSON or YAML spec file under the x-cortex-link block, with the type openapi.
If you have specs checked into your git repository, you can embed it by adding it as a relative URL with type openapi. For example:
In addition to providing the ability to link to specs within the service repo, Cortex also allows for links that reference other git repositories that aren't necessarily associated with your entity but still within your organization.
Power users can also specify a branch parameter between the second and the third colon separated group, in the form github:org/repo:branch:path/to/file. If this parameter is omitted, we will use the repository's default branch.
Using your Cortex tag, you can also send your OpenAPI JSON or YAML file to the public /api/v1/catalog/documentation/openapi for each of your entities. One API doc per entity can be uploaded and it will automatically show up as an API Doc entry in the dropdown in the API explorer.
The request body is the following, in JSON format. See API Docs for authentication details.
spec
string
The json or yaml as a string
Converting YAML or JSON to string You can use a lightweight utility like jq to take your yaml/json and generate a string that can be used for your request:
e.g. $(cat my_file.yaml | jq -Rsa)
You may have existing or external specs you want to display in the API explorer from sources such as Swagger Hub or GitHub Raw URL. Add these to the JSON or YAML spec file under the x-cortex-link block, with the type async_api.
If you have specs checked into your Git repository, you can embed it by adding it as a relative URL with type async_api. For example:
Cortex supports embedding charts from Datadog, Grafana, or New Relic directly into an entity for quick access. To view embedded charts, click the Dashboard page in the entity's sidebar.
You can add charts to an entity's YAML:
The type field is an optional enum of three types: datadog, grafana, or newrelic.
The url field is the src value for the iframe embed generated by your dashboard tool.
You must use your tool's embed URL for individual charts.
The URL must be publicly accessible. Or, if you can access the iFrame via VPN, it should be accessible in Cortex while also on the VPN.
It is possible to display content from a source other than Datadog, Grafana, or New Relic. To do this, do not specify an option for the type field. The URL you add must be publicly accessible or provide cross-platform authentication for Cortex to view and display the iframe. For example, if the content is accessible via VPN, then you should be able to view it in Cortex while on the VPN.
If you have configured the Slack integration, you can use Slack Bot commands to list documentation directly in Slack:
/slack links <tag-or-id> to list all documentation links for an entity
/slack links [type] <tag-or-id> to list specific types of documentation links for an entity
The type corresponds to the type of documentation (e.g., openapi, documentation, etc.). Replace <tag-or-id> with the entity's tag or ID.
For example:
To list all documentation links for an entity with ID en29f044598b112345, you could run the following command in Slack:
/cortex links en29f044598b112345
To list the OpenAPI specs for an entity with tag plugin-extension, you could run the following command in Slack:
/cortex links openapi plugin-extension
This documentation page walks you through configuring internal integrations with Axon Relay.
Cortex Axon uses an open-source project published by Snyk called Snyk Broker. Snyk Broker uses WebSockets to create a secure tunnel between the internal network and cloud-hosted Cortex. HTTP requests are redirected through this WebSocket channel to the Axon agent. You do not need to open inbound firewall ports, as the tunnel is initiated from the internal network.
When deploying Axon, you provide your API tokens or credentials as secrets stored on infrastructure you own, within your network. Axon securely holds these credentials and uses them to proxy requests to third-party integrations. Your sensitive information stays inside your virtual private cloud (VPC) and is never exposed to Cortex cloud services.
This is what the process looks like:
On the Cortex side, you register the integration, using an alias name you provide.
The Cortex Axon Docker container is started with your Cortex API key, the integration type, and the alias.
The Cortex Axon agent connects to the Cortex service, authenticates, and registers itself with the integration type and alias name.
The agent starts an instance of the snyk-broker client process, and uses configuration details from the /register call (the registration in the previous step) to connect to the Cortex backend instance of the snyk-broker server.
Once this is established, API calls made on the Cortex side are relayed to the internal network, and the responses are relayed back to the Cortex service.
Axon is composed of an agent which runs in a Docker container (cortex-axon-agent) and integrates with Kubernetes, creating a secure tunnel between the broker and Cortex.
Before getting started:
Create an API key in Cortex.
Create authentication credentials for the integration you're configuring.
In Cortex, click Integrations. Search for the integration you are setting up, then click +Install.
For the configuration type, select Relay.
In the side panel, enter an alias and configure any other necessary fields. At the bottom, click Save.
Locally on your machine, create a file called .env. Inside the file, add contents for the integration you are configuring:
See the variables for your integration in the README.
For example, for GitLab you would add:
To run the agent in Kubernetes, you'll need to create a Deployment that runs the agent with similar configuration as described above.
There is a Helm chart available that can be used as a starting point. Its critical variables are:
If you have a proxy setup you can add values such as:
Locally on your machine, create a file called docker-compose.yml. Inside the file, add contents for the integration you are configuring:
GitHub:
Additional environment variables include: GITHUB_API=https://api.github.com, GITHUB_TOKEN
GitHub Hosted:
Additional environment variables include: GITHUB=https://github.mycompany.com, GITHUB_TOKEN
GitHub App:
Additional environment variables include: Arg -s app, GITHUB=https://github.com, GITHUB_APP_CLIENT_ID, GITHUB_APP_CLIENT_PEM (either path to PEM or PEM contents), GITHUB_INSTALLATION_ID
Bitbucket Cloud:
Bitbucket Hosted:
Jira:
Jira Bearer/Cloud:
Additional variables include: Arg -s bearer
In a production environment, you will use a Helm chart, provided by Cortex.
In your CLI, run the command docker compose up.
You should see the agent start and connect to Cortex.
Verify that your agent is working:
In Cortex, go to Integrations then navigate to your integration's settings page.
Next to the Relay configuration you set up in the previous steps, click the play icon to test the integration.
If you watch the logging output in your CLI, you should see the agent receive the request and forward it to your internal service.
The page in Cortex should display a success message.
See examples of using Axon with unsupported tools in the Cortex Axon repository.
Before getting started:
Create a Buildkite API access token with read-only permissions for pipelines and builds.
You must be a member of a Buildkite organization to generate and use an access token for it.
In Cortex, navigate to the Buildkite settings page.
Click Integrations from the main nav. Search for and select Buildkite.
Configure the Buildkite integration form:
API token: Enter your Buildkite API token.
Organizational slug: Enter the slug for your Buildkite organization.
This can be found in your organization's Buildkite settings, or at the end of your Buildkite URL after navigating to Pipelines.
Click Save.
By default, Cortex will use the Cortex tag (e.g. my-entity) for your Buildkite pipeline. For example, if your Cortex tag is my-pipeline, then the corresponding pipeline tag in Buildkite should also be my-pipeline.
Cortex will also use the the GitHub, GitLab, Bitbucket, or Azure DevOps repository to connect entities to Buildkite pipelines. For example, if the GitHub repo associated with your Buildkite pipeline is my-org/repo, then entities in Cortex that also live in my-org/repo will populate with details from that pipeline.
You can add Buildkite pipelines to an entity by defining the pipeline slug or tags with one of the following blocks in the entity descriptor:
slug
Slug for the Buildkite pipeline
✓
tag
Tag for the Buildkite pipeline
✓
The slug for your pipeline can be found in the Buildkite URL for a given pipeline (e.g., https://buildkite.com//).
Once the Buildkite integration is established, Cortex will automatically pull in pipeline data to an entity's page. You can access this data from the CI/CD page in the entity's side panel.
You can find a list of pipeline runs for each pipeline linked to a given entity on this page:
Pipeline slug/tag
Action (e.g. "scheduled build")
Timestamp
Branch
State
The state for a build will appear as a tag next to the pipeline slug/tag (e.g. canceled, passed, or failed).
With the Buildkite integration, you can create Scorecard rules and write CQL queries based on Buildkite pipelines.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Mend Software Composition Analysis (SCA): This product scans for vulnerabilities in your third-party libraries.
See the tabs below for instructions on configuring Mend SAST and Mend SCA.
Prerequisite
Before getting started, create an API token in Mend.
If you're using a self-hosted instance of Mend, you'll need to verify that your Cortex instance is able to reach the Mend instance. We route our requests through a static IP address. Reach out to support at [email protected] to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your Mend instance.
Configure the integration in Cortex
In Cortex, navigate to the Mend settings page:
Click Integrations from the main nav. Search for and select Mend.
Click Add configuration.
Configure the Mend SAST integration form:
API token: Enter the API token you created in Mend.
Click Save.
Prerequisite
Before getting started, create an and a in Mend.
If you're using a self-hosted instance of Mend, you'll need to verify that your Cortex instance is able to reach the Mend instance. We route our requests through a static IP address. Reach out to support at to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your Mend instance.
Configure the integration in Cortex
In Cortex, navigate to the :
If you’re unable to expose your Mend instance to be reachable by Cortex, you can set up a Custom Integration Webhook.
By default, Cortex will use your associated Git repository (e.g. repo-name) as the "best guess" for the Mend SAST application name and the Mend SCA project name.
If your repository names don’t cleanly match the Mend SAST application names or Mend SCA project names, you can override this in the Cortex Service Descriptor.
The application IDs can be found in the Mend SAST web interface.
A project ID can be found in the Mend SCA web interface; while viewing the project, the ID appears in the URL after project;id=.
From the Overview tab on an entity page, you can find vulnerabilities in the Code and Security block.
In the left sidebar of an entity, click Code & security > Mend to view the total number of vulnerabilities, a risk score, and a list of vulnerabilities including the risk rating and creation date.
With the Mend integration, you can create Scorecard rules and write CQL queries based on Mend projects and applications.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
To display domains in a hierarchy:
Click Display at the top of the domains list.
Enable to toggle next to Display hierarchy.
Click Done.
You can also view the hierarchy for a given domain on its entity details page. If the domain has parents or children, those will appear on the Relationships page.
In the entity's side bar, click Relationships, then click the Hierachy tab.
At the top of the domain, click View in domains tree to visualize your domain hierarchy in the relationship graph.
You can create domains:
By importing them from a connected integration
Manually in the Cortex UI
Via the entity descriptor YAML through GitOps
Via the
For simplicity, we recommend adding the highest-level domain first and then selecting it as the parent for subsequent domains. However, you can add parents and children to any domain at any point.
Importing domains
You can import domains directly from third-party integrations:
In Cortex, navigate to Catalogs > All entities, then click Import entities.
Choose Import discovered entities.
Select the integration to import from.
On the following page, after the integration sync is complete, a list of entities from the integration are displayed. Check the boxes next to any entities you want to import.
If you have a large volume of entites, click Filter in the upper right corner of the results list to select and apply entity type filters.
At the bottom of the page, click Next step.
Edit the details for the entity:
Type: Select Domain.
Entity name: Enter a human readable name.
Identifier: This field is auto-populated based on your entity name. It is a unique identifier for your entity. This is also known as the x-cortex-tag
If you selected more than one entity: After the first entity is configured, click the name of the next entity on the right to navigate to the detail editor for that entity.
Click Confirm import.
Manually creating domains
In the main nav of Cortex, click Catalogs > Domains.
At the top of the Domains page, click +Import entities.
Choose Create entities manually.
The hierarchy of entities in Cortex is based on that hierarchy being defined in the entity's YAML file; Cortex does not set hierarchies based on a YAML file's location in your repository.
Domain entity descriptor
If your entity is a domain, you must specify x-cortex-type as domain:
Domain hierarchies
These can be defined in two ways:
From the parent entity YAML
Creating domains via the API
You can create, update, and delete domains using the .
It is possible to edit entities after creating them:
Navigate to the entity's page.
In the upper right corner, click Configure entity.
Make any desired changes.
Note: The only field you cannot edit is the identifier.
At the bottom of the screen, click Save changes.
Under Settings > Entities > Domains, you can enable automatic import of domains and domain relationships from ServiceNow.

The Velocity Dashboard visualizes your team's success across the software development lifecycle.
The Copilot Dashboard provides insight into Copilot adoption and engagement across your engineering teams.
Custom Dashboards allow you to create shared views of the key engineering metrics that matter most to your organization
Metrics Explorer: Analyze trends over time and drill into the underlying data for investigation. Explore metrics for deploys, version control, project management (Jira), and incident management (PagerDuty).
Custom metrics: The ability to define your own custom time series metrics to power the analytics in Eng Intelligence, drawing from your integrations with Cortex or your organization's internal data. Currently custom metrics are only available in the All Metrics (Classic View) but planned to be added to the new experiences.
Learn about measuring success with Eng Intelligence below.
In practice, success means that teams are not only tracking metrics like cycle time, deployment frequency, change failure rate, and mean time to recovery (MTTR), but they are also taking action to make progress based on how the metrics are trending. The focus should be less about hitting specific benchmarks and more about creating continuous feedback loops that drive consistent improvement.
Eng Intelligence metrics provide clear, actionable insights into how your teams work, allowing you to find opportunities to improve delivery speed, reliability, and quality.
Before setting goals, we recommend establishing a baseline on your top-priority metrics.
Leading indicators show that teams are learning from Eng Intelligence metrics and effectively making changes in their day-to-day work. For example:
Faster feedback loops: Time to first PR review, Time to PR approval, and Work item lead time steadily decrease over a given period.
Smaller, more frequent PRs: PR size trends downward while merged PR count increases.
Balanced workloads: More unique PR authors over time, showing distributed contribution. For project management metrics, a balance of Work items created and Work items completed shows healthy workload management.
Proactive incident management: Change failure rates decrease as deploy insights are integrated.
Lagging indicators can measure whether your organization is seeing tangible improvements in delivery and reliability. For example:
Cycle time improves from baseline.
Deployment frequency increases without increased failure rates.
MTTR decreases after incidents.
Higher engineering satisfaction is reported in internal surveys as bottlenecks are resolved.
The backlog of work items created stabilizes or decreases while work items are steadily being completed, indicating the team is successfully matching capacity to demand.
To make your data more meaningful, we recommend the following best practices:
Segment by teams and services to avoid skewed organization-wide averages.
Look for trends rather than snapshots. Success is measured over time; a short-term fluctuation can be misleading.
When you identify process gaps with Eng Intelligence, take action to drive adoption of standards: Use Scorecards or Initiatives to encourage your teams to get their owned services aligned with standards. Use Workflows to streamline repeatable tasks for engineers so they can focus on other work.
The following are common ways to confirm successful use of Eng Intelligence features:
Leadership uses the dashboards to make strategic decisions (e.g., during planning cycles).
Teams are actively using the dashboards to spot bottlenecks.
Metrics drive measurable changes in process, tooling, and culture.
Improvements are sustained and repeatable, not just short-term spikes.
To get started, click Eng Intelligence from the main nav in Cortex.
See the docs for more information on each part of Eng Intelligence:
Trigger xMatters incidents from Cortex
Create Scorecards that track progress and drive alignment on projects involving your xMatters services
In Cortex, navigate to the xMatters settings page:
Click Integrations from the main nav. Search for and select xMatters.
Click Add configuration.
Configure the xMatters integration form:
Username and Password: Enter your xMatters username and password.
Organization slug: Enter the organization slug for your xMatters instance.
This can be found in the URL for your instance (e.g., https://.xmatters.com)
Click Save.
While viewing an entity in Cortex, you can trigger an incident in xMatters:
In Cortex, navigate to an entity. On the left side of an entity details page, click On-call & incidents.
In the upper right side of the entity's "On-call" page, click Trigger incident.
Configure the incident modal:
Summary: Enter a title for the incident.
Description: Enter a description of the incident.
Severity: Select a severity level.
At the bottom of the modal, click Trigger incident.
A confirmation screen will appear. In the confirmation, click the link to view the incident in xMatters.
By default, Cortex will use the Cortex tag (e.g. my-entity) as the "best guess" for xMatters group. For example, if your Cortex tag is my-entity, then the corresponding group in xMatters should also be my-entity.
If your xMatters group don’t cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
id
Name of the group in xMatters
✓
type
SERVICE
✓
Once the integration with xMatters is configured, you'll be able to find the user or team on call in the Current On-call block on an entity's details page.
You can find more detailed information from the xMatters integration in the entity sidebar under On-call & incidents > xMatters.
The schedule associated with a given entity will be hyperlinked in the Escalation Policy block and the group will be hyperlinked in the Service block.
Under the Escalations section, you'll find each level associated with the policy. Owners assigned to each level will also be hyperlinked to the user or team's on-call page in xMatters.
With the xMatters integration, you can create Scorecard rules and write CQL queries based on xMatters services.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Before getting started:
Create an incident.io API key with the following scopes:
Create incidents
View all incident data, including private incidents
View data like public incidents and organization settings
View catalog types and entries
In Cortex, navigate to the incident.io settings page:
Click Integrations from the main nav. Search for and select incident.io.
Click Add configuration.
Configure the incident.io integration form:
Account alias: Enter the alias for your configuration.
API key: Enter your incident.io API key.
Click Save.
Configure the integration for multiple incident.io accounts
The incident.io integration has multi-account support. You can add a configuration for each additional instance by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated instance with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the incident.io page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
By default, Cortex will try to "best-guess" the corresponding custom field value in incident.io for all catalog-based custom fields.
Cortex first looks up a custom field values using the name (e.g. My Entity), then the entity identifier (e.g. my-entity). For example, if your entity name is "My Entity," then the corresponding custom tag field in incident.io should either be "My Entity" or "my-entity."
name
Name for the entity (from customFieldName)
✓
value
Display name for the entity in Cortex
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
id
ID for the entity (from customFieldID)
✓
value
Tag for the entity in Cortex
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
Once the integration is set up, incident data will appear on entity details pages.
Active incidents detected in incident.io will appear on an entity's details page in the Operations block under the Overview tab. More detailed information is also available under the Operations tab.
Incident data will also be pulled into the incident.io page under the On-call & incidents page in the entity's sidebar.
While viewing an entity in Cortex, you can trigger an incident in incident.io:
In Cortex, navigate to an entity. On the left side of an entity details page, click On-call & incidents.
In the upper right side of the entity's "On-call" page, click Trigger incident.
Configure the incident modal:
Summary: Enter a title for the incident.
Description: Enter a description of the incident.
Severity: Select a severity level.
At the bottom of the modal, click Trigger incident.
A confirmation screen will appear. In the confirmation, click the link to view the incident in incident.io.
With the incident.io integration, you can create Scorecard rules and write CQL queries based on incident.io incidents.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Create Scorecards that track progress and drive alignment on projects involving incidents
Before getting started:
Create an API token in Rootly. Ensure the Rootly user account represented by the API key has admin permissions in Rootly.
In Cortex, navigate to the Rootly settings page:
Click Integrations from the main nav. Search for and select Rootly.
Click Add configuration.
Configure the Rootly integration form:
Account alias: Enter the alias for your configuration.
API token: Enter your Rootly API token.
Click Save.
Once you save your configuration, you'll see it listed on the integration's settings page in Cortex. If you’ve set everything up correctly, you’ll see the option to Remove Integration in Settings.
You can also use the Test all configurations button to confirm that the configuration was successful. If your configuration is valid, you’ll see a banner that says “Configuration is valid. If you see issues, please see documentation or reach out to Cortex support.”
Configure the integration for multiple Rootly accounts
The Rootly integration has multi-account support. You can add a configuration for each additional instance by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated instance with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the Rootly page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
You can view incidents on an entity details page. Each incident is listed with its title, severity, status, and description.
To view the list of incidents:
In Cortex, navigate to an entity.
On the left side of the entity details page, click On-call & incidents.
In the list, view all incidents from the last 30 days. To narrow the list by severity or or status, use the filters at the top of the page.
In addition, active incidents will appear at the top of the entity details overview page.
By default, Cortex will use the Cortex tag (e.g. my-entity) or entity name as the "best-guess" for a Rootly service. For example, if your Cortex tag is my-entity, then the corresponding service slug in Rootly should also be my-entity.
If your Rootly service name does not match the Cortex tag or name, you can override this in the Cortex entity descriptor.
For a given entity, you can define Rootly services by ID or slug.
id
Service ID
****
slug
Service slug
****
While viewing an entity in Cortex, you can trigger an incident in Rootly:
In Cortex, navigate to an entity. On the left side of an entity details page, click Integrations > Rootly.
In the upper right side of the entity's Rootly page, click Trigger incident.
Configure the incident modal:
Name: Enter a name for the incident.
Summary: Enter a summary for the incident.
Description: Enter a long-form description of the incident.
Severity: Select a severity level.
Condition: Select a condition for the incident.
At the bottom of the modal, click Trigger incident.
A confirmation screen will appear. In the confirmation, click the link to view the incident in Rootly.
With the Rootly integration, you can create Scorecard rules and write CQL queries based on Rootly incidents.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Domains
See a hierarchical diagram of your software architecture
Teams
View your company's team structure
You can access the relationship graph in different ways:
From the main nav: Navigate to Tools > Relationship graphs. By default, the page displays all entities with dependencies and how they relate to one another.
From an entity details page:
While viewing an entity, click the Dependencies tab. In the row containing the entity you want to view in a graph, click the 3 dots icon, then click View in relationship graph.
While viewing a domain or team entity, locate an entity under the Hierarchy header. In the row containing the entity you want to view in a graph, click the 3 dots icon, then click View in relationship graph.
At the top of the page, choose which relationships you want to view: Dependencies, domains, or teams.
You can apply filters to narrow the scope of the graph:
Click Filters at the top of the page.
Apply filters for the following options:
Sources
Groups
Entity types
Degrees from selected node
The page will automatically apply your selected filters and reload the visualization.
At the top of the graph, click Display options to select:
A Scorecard to filter the graph by
Whether to hide team nodes without children
Whether to hide archived entities
In the graph, click an entity to open a modal with the ability to:
Filter by this node
Go directly to its entity details page
View a list of its child entities or dependencies
You must have the Configure settings permission.
Under Settings > Relationship graph, you can select whether to display dependencies, domains, or teams by default when you first open the relationship graph.
Before getting started, create a Lightstep API key.
In Cortex, navigate to the Lightstep settings page:
Click Integrations from the main nav. Search for and select Lightstep.
Click Add configuration.
Configure the Lightstep integration form:
Org ID: Enter your Lightstep organization ID.
You can find this in your Lightstep project settings.
Project ID: Enter the Lightstep project ID.
You can find this in your Lightstep project URL, e.g., https://app.lightstep.com/PROJECT_ID/project
Click Save.
You can create and manage SLOs by listing relevant latency SLIs through Streams. Cortex will pull data from Lightstep, and track against your specified SLO. For example:
streamId
ID of your Lightstep stream, which can be found in Lightstep, through the URL. https://app.lightstep.com//stream/my-stream/
percentile
Percentile latency for your given streamId, out of 1
target
Latency targets in ms. Latency is currently the only target supported
slo
SLO percentile, out of 1
When an SLO is defined in an entity's descriptor, you'll see detailed data about SLOs in the Overview tab.
On the left side of an entity, click Monitoring > Lightstep to view the SLO query, target(s), current value for each SLO, a graph of SLO performance over time, and the period of time the SLO is being calculated for. For example, if the time listed is "7 days ago," then the SLO is looking at the time range starting 7 days ago to now.
With the Lightstep integration, you can create Scorecard rules and write CQL queries based on Lightstep SLOs.
See more examples in the CQL Explorer in Cortex.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .






Custom data extends the out-of-the-box metadata that Cortex provides via integrations, enhancing your use of catalogs and augmenting details available for your entities. This data can also be used to write CQL queries and Scorecard rules.
Custom data can be defined manually in the entity descriptor, added to entities programmatically via a REST API, or sent through a webhook. To learn about sending data via webhook, see Custom webhook integrations.
Cortex also offers a custom metrics feature for Eng Intelligence. Note the following differences between custom data and custom metrics:
Custom data should be used when you need to attach static or slowly changing metadata to entities, such as deployment environments, compliance statuses, or other descriptive attributes. It is best for enriching entity details, reporting, and Scorecard rules based on entity attributes. Learn more below in .
It is not ideal for tracking dynamic or time-sensitive information, as new data will overwrite previous values for the same key.
Custom metrics should be used to track time series or trending data, such as incident counts, SLOs, or any metric that changes over time and needs to be visualized in charts or analyzed in Eng Intelligence. Learn more in .
Custom metrics are designed for analytics and can be used in dashboards, entity pages, and Scorecards.
There are a few ways you can add custom data to an entity:
In the entity descriptor
This is optimal for low-volume, human-maintained data because it requires updating the entity's YAML when the data changes.
Via a POST REST API endpoint
Editing the entity descriptor
The simplest way to describe information in the YAML is to define an object.
Cortex applies a data source hierarchy to determine how to handle a case where the same key is defined from multiple sources.
The is the source of truth. If a key is defined there, the API or webhooks cannot override the key.
The and approaches are at the same level and can override each other.
You can override keys defined in the YAML by adding a force=true parameter when using an API, but when the entity descriptor is eventually re-processed, the data provided via the API will be overwritten.
Catalogs contain a lot of useful metadata about entities, including ownership and data from integrations. However, you may have your own custom fields that you want to include that would make exploring the catalog easier.
These can include things like:
Which AWS zones is this deployed in?
What databases does the entity consume?
When was the last successful CI run?
If the answers to these questions fit a pre-enumerated list, consider using . Groups are displayed on entity detail pages and can easily be applied in catalog filters.
Custom data for cataloging makes the most sense when the data is more flexible.
Custom data can then be queried against by using the , explored with , or viewed on an .
Cortex makes it easy to write based on custom data that exists in your catalogs. When adding a rule, you can select Custom data from Choose an integration in the form editor and follow the flow. Cortex will automatically supply variables based on the custom data you've defined.
Using the to push data into Cortex and extend your Scorecards. You can send entire JSON payloads and use jq to process them in a Scorecard, or use it as an input to a custom OPA Policy as a Scorecard rule.
Sync your data to power your internal developer portal. Cortex supports third-party integrations, internally hosted integrations, and custom webhook integrations.
All users can view the integration page to see what is configured and whether your configurations are healthy. Users must have the Configure Integrations permission to install, uninstall, and configure integrations.
Cortex uses official APIs provided by each tool to pull live data directly from your systems. This means when you're viewing an entity, you're seeing the most current information with no manual syncing or stale data to manage.
Cortex supports integrations across essential use cases for engineering excellence:
You can source data from an internally-hosted system and reflect that data in Cortex. See for more information.
You can use custom data webhooks to create unique URLs that you can use to directly POST arbitrary JSON payloads without authentication headers or a Cortex tag. See for more information.
Cortex offers the following integrations for SSO access to your Cortex workspace:
Cortex has built a distributed self-throttling system to ensure that certain functionality, such as CQL evaluations or background syncs to pull data from integrations, are not going over the rate limit thresholds for specific vendors. It handles different rate limit thresholds for different APIs within the same integration, which is common for git APIs such as Bitbucket.
The system is designed to proactively throttle before hitting a 429 from the vendor, and it works regardless of how many evaluators are trying to access that integration. Note that this system does not track other requests with the same token or undocumented limits set by vendors.
While viewing an integration's settings page, click the Logs tab to view error logs from the last 7 days. You can filter the logs list by configuration and by operation (for example, you could filter to view errors surfaced only via Scorecards).
Click into a log to get more information, including time stamp, status code, full error, request path, and more, enabling you to troubleshoot integration issues.
Snyk is a cybersecurity platform that scans for and surfaces vulnerabilities across your codebase.
Integrating Snyk with Cortex allows you to:
View vulnerabilities on entity pages in Cortex, quickly connecting issues to entities and their owners
Enhance the Snyk experience by aggregating issues into an entity's event timeline so they can be understood in the context of other events, like deploys and on-call incidents
Use to measure entity quality based on Snyk data and drive quality improvements to your security practices
Before getting started:
Create a . The token will need the following read permissions:
View Organization Reports: Lists reporting issue counts.
View Organization: Allows Cortex to get a flattened list of all projects across all orgs.
Once you've created an API token in Snyk, you can create a configuration from .
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select Snyk.
Click Add configuration.
Configure the integration form:
After saving your configuration, you are redirected to the Snyk integration settings page in Cortex. On this page, you'll see a list of detected organizations pulled from Snyk, along with the unique Snyk ID and internal name associated with each organization.
Cortex uses the Git repository as the "best guess" for the corresponding Snyk project since Snyk projects are connected to repositories. Cortex will search for all Snyk projects across all Snyk organizations and pull in projects associated with the same repository. For example, if the GitHub repo associated with your Snyk instance is my-org/repo, then the entities in Cortex should also be associated with my-org/repo.
You can define projects under the x-cortex-snyk block:
You can define organization with the organization ID or its slug in Snyk.
Once the Snyk integration is set up, you'll be able to find information about vulnerabilities for each entity linked to a discovered repo.
On an overview, see vulnerabilities listed under the Code & security block. Within this block, issues and vulnerabilities are grouped by severity: Critical, High, Medium, and Low. Click into any of these to open a list of all applicable issues and vulnerabilities.
In an entity's sidebar, click Code & security > Snyk to view detected issues and vulnerabilities from Snyk, including the associated organization name and project name.
Because Snyk aggregates problems as "issues," data pulled in from Snyk will be listed as issues, while data pulled in from a Git source will be listed as vulnerabilities.
Vulnerabilities pulled from Git sources display the project name and a severity tag. Each issue pulled from Snyk displays the following information, when available:
Title
Issue ID (linked to the issue in Snyk)
Publish date
Severity tag
Event timeline
Issues from Snyk and vulnerabilities detected in Git appear in the entity's event timeline, which you can find from the Events link in the entity's sidebar. Issues and vulnerabilities display alongside other events, such as K8s changes, Git commits, and on-call incidents.
With the Snyk integration, you can create Scorecard rules and write CQL queries based on Snyk projects.
See more examples in the in Cortex.
Snyk does not currently support aggregated issues in regions outside of the U.S.A. Please use .issues() rather than .numOfIssues() if in a non-U.S.A. region.
Cortex fetches issues and vulnerabilities from Snyk and Git sources in real time. Depending on the volume of data, it may take additional time for the data to load on an entity page.
Projects from Snyk are synced every 6 hours.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Dynatrace is a monitoring and observability platform. Integrate Dynatrace with Cortex to get insights into application performance, service discovery, SLOs, and dependencies.
Before getting started, generate an with the scopes Read entities and Read SLO.
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Dynatrace.
Click Add configuration.
Configure the Dynatrace integration form:
If you’ve set everything up correctly, you’ll see the option to Remove Integration in settings.
You can also use the Test configuration button to confirm that the configuration was successful. If your configuration is valid, you’ll see a banner that says “Configuration is valid. If you see issues, please see documentation or reach out to Cortex support.”
See the for instructions on importing entities.
Entity ID
Entities with a type of "SERVICE" will be discovered and surfaced. When using the Dynatrace portal, service IDs can be found in the URL of a selected service under the id query param. For example, https://.live.dynatrace.com/#newservices/serviceOverview;id=
Entity name
You can also match entities based on matching with a regular expression, like:
Dynatrace supports service-level objective (SLO) monitoring. You can link these SLOs to your Dynatrace entity in Cortex:
In Dynatrace, navigate to the Service-Level Objectives app.
On the left sidebar of Dynatrace, click Search, then type in slo to find the app.
On the SLOs page, see the list of SLOs. On the right side of an SLO, click ^ to expand the Details.
At the bottom of the page, click Save.
After saving, navigate back to your service details page to view the SLO status in the service's Overview tab.
For information on working with SLOs in Dynatrace, see .
Cortex automatically syncs from Dynatrace using attributes inherent to each entity.
Cortex will pull recent changes from your Dynatrace instance into the . Here, you can find new entities in Dynatrace that have not been imported into the catalog - these will have the tag New APM resource - as well as entities in the catalog that no longer exist in Dynatrace - these will have the tag APM resource not detected.
With the Dynatrace integration, you'll see SLOs on an entity's home page. High-level information about SLOs appears in the Overview tab.
Click Monitoring in the entity's sidebar to see more detailed data: the SLO name, its target, the current value for that entity, and the period of time the SLO is being calculated for. For example, if the time listed is "7 days ago," then the SLO is looking at the time range starting 7 days ago to now.
detected from Dynatrace will appear in .
With the Dynatrace integration, you can create Scorecard rules and write CQL queries based on Dynatrace SLOs.
See more examples in the in Cortex.
Cortex conducts a background sync of Dynatrace entities at 7 a.m. UTC and a dependency sync every day at 12 a.m. UTC. You can via the Relationship Graph.
is a project management tool that combines tasks, document collaboration, and issue management in a single platform.
Integrating ClickUp with Cortex allows you to:
View task information directly on in Cortex
Create ClickUp tasks based on Initiatives directly from Cortex
Map ClickUp identities to users in Cortex
We’re excited for you to start using Cortex to achieve engineering excellence! If you don’t have an account yet, .
This guide walks through setting up your account, configuring your first integrations, and connecting your — services, infrastructure, teams, and more — with Cortex. After you’ve followed these steps, reach out to the Cortex team with any questions you have.
To ensure a smooth implementation, partner with Cortex Professional Services (PS) for expert guidance and hands-on assistance with data modeling, entity ownership, and more. Reach out to [email protected] to learn how we can support your implementation and adoption journey.
Each entity has its own page that centralizes data related to the entity, allowing developers to reduce context switching.
While viewing entities in a catalog, or from the Catalogs > All entities page, click an entity name to open that entity's details page and see an overview of important information:
If there are any active incidents, you will see them at the top of the page.
In the sidebar, you want to see. Pin key information for easier visibility and access. You can include data for on-call, owners, Slack or Microsoft Teams channels, groups, repository, entity relationships, docs links, project management, custom data, and code quality.
In Cortex, you have the ability to define outgoing dependencies on other entities. Cortex can also automatically for some integrations. Having dependencies defined powers the ability to when a dependency deprecates its API or makes backwards incompatible changes, and the ability to visualize dependencies in a .
Incoming dependencies are inferred based on the outgoing dependency definitions.
In Cortex, you can visualize dependencies using the relationship graph at Tools > Relationship graphs. See the for more information.
docker pull ghcr.io/cortexapps/cortex-mcp:latest{
"mcpServers": {
"cortex": {
"command": "docker",
"args": [
"run",
"--rm",
"--pull",
"always",
"-i",
"--env",
"CORTEX_API_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN_HERE",
"ghcr.io/cortexapps/cortex-mcp:latest"
]
}
}
}{
"mcpServers": {
"cortex": {
"command": "docker",
"args": [
"run",
"--rm",
"--pull",
"always",
"-i",
"--env",
"CORTEX_API_TOKEN=YOUR_ACCESS_TOKEN_HERE",
"--env",
"CORTEX_API_BASE_URL=https://api.cortex.company.com",
"ghcr.io/cortexapps/cortex-mcp:latest"
]
}
}
}{
"mcpServers": {
"cortex": {
"command": "docker",
"args": [
"run",
"--rm",
"--pull",
"always",
"-i",
"-v",
"/path/to/your//company_certs.ca:/etc/ssl/certs/company-ca.crt:ro",
"--env",
"REQUESTS_CA_BUNDLE=/etc/ssl/certs/company-ca.crt",
"--env",
"SSL_CERT_FILE=/etc/ssl/certs/company-ca.crt",
"--env",
"CURL_CA_BUNDLE=/etc/ssl/certs/company-ca.crt",
"--env",
"CORTEX_API_TOKEN=YOUR_ACCESS_TOKEN_HERE",
"--env",
"CORTEX_API_BASE_URL=https://api.cortex.company.com",
"ghcr.io/cortexapps/cortex-mcp:latest"
]
}
}
}export CORTEX_API_TOKEN=VALUE_OF_YOUR_PERSONAL_ACCESS_TOKEN
cat << EOF > ~/Library/Application\ Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"cortex": {
"command": "docker",
"args": [
"run",
"--pull",
"always",
"--rm",
"-i",
"--env",
"CORTEX_API_TOKEN=${CORTEX_ACCESS_TOKEN}",
"ghcr.io/cortexapps/cortex-mcp:latest"
]
}
}
}
EOFopenapi: 3.0.1
info:
title: My Service
description: This is my cool service.
x-cortex-tag: my-service
x-cortex-type: serviceopenapi: 3.0.1
info:
title: Chat Service
description: Chat service is responsible for handling chat feature.
x-cortex-tag: chat-service
x-cortex-type: service
x-cortex-parents: # parents can be of type domain only
- tag: notifications-domain
- tag: support-domain
x-cortex-groups:
- python
x-cortex-owners:
- type: group
name: Delta
provider: OKTA
description: Delta Team
x-cortex-slack:
channels:
- name: delta-team
notificationsEnabled: true
description: This is a description for the delta-team Slack channel # optional
x-cortex-link:
- name: Chat ServiceAPI Spec
type: OPENAPI
url: ./docs/chat-service-openapi-spec.yaml
x-cortex-custom-metadata:
core-service: true
x-cortex-dependency:
- tag: authentication-service
- tag: chat-database
x-cortex-git:
github:
repository: org/chat-service
x-cortex-oncall:
pagerduty:
id: ASDF1234
type: SCHEDULE
x-cortex-apm:
datadog:
monitors:
- 12345
x-cortex-issues:
jira:
projects:
- CSx-cortex-servicenow:
services:
- tableName: cortex-services
id: 1x-cortex-owners:
- type: group
name: My ServiceNow Team
provider: SERVICE_NOW
description: This is a description for this owner # optionalownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)ownership.teams().all(team => team.description != null and team.isArchived == false)x-cortex-wiz:
projects:
- projectId: 01234567-e65f-4b7b-a8b1-5b642894ec37wiz != nullwiz.issues(statuses = ["OPEN"]).length <= 3wiz.issues(severity = ["CRITICAL", "HIGH"]).length < 10wiz.issues().length < 25x-cortex-link:
- name: My GitHub Spec
type: OPENAPI
url: github:org/repo:path/to/filex-cortex-link:
- name: My GitLab Spec
type: OPENAPI
url: gitlab:namespace/project:path/to/filex-cortex-link:
- name: My Azure DevOps Spec
type: OPENAPI
url: azuredevops:project/repository:path/to/filex-cortex-link:
- name: My Bitbucket Spec
type: OPENAPI
url: bitbucket:workspace/repo:path/to/filex-cortex-link:
- name: My Spec
type: OPENAPI
url: ./docs/my-openapi-spec.yamlx-cortex-link:
- name: My Spec
type: ASYNC_API
url: ./docs/my-spec.ymlx-cortex-dashboards:
embeds:
- type: datadog | grafana | newrelic (optional)
url: https://example.comCORTEX_API_TOKEN=your_cortex_token
GITLAB_TOKEN=your_gitlab_token# Example for github
relay:
integration: github # can be blank
subtype: # optional, can be blank, see table above for options
alias: alias for configuration from Cortex
env:
GITHUB: "https://github.com"
GITHUB_API: "https://api.github.com"
GITHUB_GRAPHQL_API: "https://api.github.com/graphql"
verbose: false # set to true to enable verbose loggingproxy:
server: http://proxy.example.com:8080
noProxy: proxy.example.com # note localhost is added automatically
certSecretName: my-proxy-ca-pem # name of the secret containing a .pem file with the CA certificateservices:
axon:
image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- GITHUB_API=api.github.com
- GITHUB_GRAPHQL=api.github.com/graphql
command: [
"relay",
"-i", "github",
"-a", "github-relay", # this is the alias you set up in the Cortex UI
# if you are using a Github App token, add the following line
# "-s", "app",
]services:
axon:
image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- GITHUB_API=https://github.mycompany.com/api/v3
- GITHUB_GRAPHQL=https://github.mycompany.com/api/graphql
command: [
"relay",
"-i", "github",
"-a", "github-relay", # this is the alias you set up in the Cortex UI
# if you are using a Github App token, add the following line
# "-s", "app",
]services:
axon:
image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- GITHUB_API=https://api.github.com
- GITHUB_GRAPHQL=https://api.github.com/graphql
command: [
"relay",
"-i", "github",
"-a", "github-relay", # this is the alias you set up in the Cortex UI
# if you are using a Github App token, add the following line
# "-s", "app",
]buildkite != nullbuildkite.pipelines().any((pipeline) => pipeline.gitRepository = )x-cortex-ci-cd:
buildkite:
pipelines:
- slug: my-buildkite-pipeline-slug-1
- slug: my-buildkite-pipeline-slug-2x-cortex-ci-cd:
buildkite:
tags:
- tag: my-buildkite-tag-1
- tag: my-buildkite-tag-2mend != nullmend.vulnerabilities(source = ["SAST", "SCA"]).length < 10mend.vulnerabilities(risk = ["Medium", "High"]).length <= 3x-cortex-static-analysis:
mend:
applicationIds:
- mend_id_1
- mend_id_2
projectIds:
- project_id_1
- project_id_2oncall != nulloncall.numOfEscalations() >= 2oncall.details().id.matches("Sample*") == truex-cortex-oncall:
xmatters:
id: engineering_group
type: SERVICEincidentio != nullx-cortex-incident-io:
customFields:
- name: Entity
value: My Entity
alias: my-default-aliasx-cortex-incident-io:
customFields:
- id: Entity_ID
value: my-second-entity
alias: my-other-aliasrootly != nullx-cortex-rootly:
services:
- id: ASDF1234x-cortex-rootly:
services:
- slug: service-slugslos().all((slo) => slo.passing) == trueslos().filter((slo) => slo.name.matchesIn("latency") and slo.sliValue >= 0.9999).length > 0x-cortex-slos:
lightstep:
- streamId: sc4jmdXT
targets:
latency:
- percentile: 0.5
target: 2
slo: 0.9995API key: Enter the API key you generated in Lightstep.











Slug
Tags
services:
axon:
image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- GITLAB_API=https://gitlab.com
- GITLAB_TOKEN=<token>
command: [
"relay",
"-i", "gitlab",
"-a", "gitlab-relay", # this is the alias you set up in the Cortex UI
] image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- BITBUCKET_API=https://api.bitbucket.org
- BITBUCKET_TOKEN=<token>
command: [
"relay",
"-i", "bitbucket",
"-a", "bibucket-relay", # this is the alias you set up in the Cortex UI
] image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- BITBUCKET_API=https://bitbucket.mycompany.com
- BITBUCKET_USERNAME=<user>
- BITBUCKET_PASSWORD=<password>
command: [
"relay",
"-i", "bitbucket",
"-a", "bibucket-relay", # this is the alias you set up in the Cortex UI
] image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- JIRA_API=https://jira.mycompany.com
- JIRA_USERNAME:<user>
- JIRA_TOKEN=<token>
command: [
"relay",
"-i", "jira",
"-a", "jira-relay", # this is the alias you set up in the Cortex UI
] image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- JIRA_API=https://mycompany.atlassian.com
- JIRA_TOKEN=<token>
command: [
"relay",
"-i", "jira",
"-a", "jira-relay", # this is the alias you set up in the Cortex UI
] image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- SONARQUBE_API=https://sonarqube.mycompany.com
- SONARQUBE_TOKEN=<token>
command: [
"relay",
"-i", "sonarqube",
"-a", "sonarqube-relay", # this is the alias you set up in the Cortex UI
] image: ghcr.io/cortexapps/cortex-axon-agent:latest
env_file: .env
env:
- PROMETHEUS_API=http://mycompany.prometheus.internal
- PROMETHEUS_USERNAME=<user>
- PROMETHEUS_PASSWORD=<password>
command: [
"relay",
"-i", "prometheus",
"-a", "prometheus-relay", # this is the alias you set up in the Cortex UI
]buildkite.builds(states["passed"]).length >=1incidentio.incidents(severity = ["SEV1"]).length < 3 incidentio.incidents(severity = ["Critical"]).filter((incident) => incident.createdAt.fromNow() > duration("-P90D")).length <= 2rootly.incidents(severity = ["SEV1"]).length < 3 rootly.incidents(severity = ["Critical"]).filter((incident) => incident.createdAt.fromNow() > duration("-P90D")).length <= 2claude mcp list and verify that cortex-remote is in the list of servers.Cursor:
Open Settings > MCP Servers and verify that cortex is listed and connected.

Groups: Select groups to segment your entity.
Owners: Define ownership for your entity. We recommend selecting team owners to keep your ownership information up-to-date through any future personnel changes.
Links: Add links to external documentation, such as runbooks, docs, logs, or custom categories.
Parents: Define parent domains. This is where you configure the hierarchy for your entity. These can be visualized in the relationship graph.
Dependencies: Select entities that this entity depends on. These can be visualized in the relationship graph.
On-call: Configure on-call information.
Repository: Select the repository associated with this entity.



Name: Enter a name for the link.
URL: Enter the URL.
Description: Add a description of the link.

Under "Integrations", click Mend.
Click Add configuration.
Configure the Mend SCA integration form:
Organization type: Select Global or Single.
Organization API token: Enter your Global organization key or a single organization key.
This can be found in Mend SCA under the .
User key: Enter your Mend user key.
This can be found in Mend under User profile > User keys.
URL type: Select your Mend URL type depending on the server URL for your Mend instance.
Select NEW if the server URL is saas.mend.io.
Select LEGACY if the server URL is saas.whitesourcesoftware.com.
Custom URL: If using a dedicated instance, enter your Mend server URL.
Click Save.
Description: Enter a description of the entity to help others understand its purpose.
Groups: Optionally select groups to segment your entity.
Owners: Define ownership for your entity. We recommend selecting team owners to keep your ownership information up-to-date through any future personnel changes. You may see owners that Cortex recommends based on repository activity. You can accept or reject the recommendations.
When adding an owner, you can also configure one of the following inheritance options:
Append: Select this option to add your entity as an additional owner to all of its child entities.
Fallback: Select this option to add your entity as an owner to child entities if the child entity has no other valid owners.
None: Select this option if you do not want to configure inheritance. The owner will own the domain you are creating, but will not be configured as an appended or a fallback owner.
Parents and Children: Define parent and children domains. This is where you configure the hierarchy for your domain. These can be visualized in the relationship graph.
On-call: Configure on-call information.
Repository: Select the repository associated with this entity.
When you are finished, click Confirm import at the bottom of the page.
Type: Select Domain.
Entity name: Enter a human readable name.
Identifier: This field is auto-populated based on your entity name. It is a unique identifier for your entity. This is also known as the x-cortex-tag.
Description: Enter a description of the entity to help others understand its purpose.
Groups: Optionally select your entity.
Owners: Define ownership for your entity. We recommend selecting team owners to keep your ownership information up-to-date through any future personnel changes.
When adding an owner, you can also configure one of the following inheritance options:
Append: Select this option to add your entity as an additional owner to all of its child entities.
Parents and Children: Define parent and children domains. This is where you configure the hierarchy for your domain. These can be visualized in the .
On-call: Configure on-call information.
Repository: Select the repository associated with this entity.
When you are finished, click Confirm import at the bottom of the page.
Define children entities using the x-cortex-children tag in the parent entity YAML.
From the child entity YAML
Define parent entities using the x-cortex-parents tag in the child entity YAML.
While defining these relationships top-down (on the parent entity) or bottom-up (on the child entity) will both result in a hierarchy, you may choose one or the other depending on your workflow. For example, if you are frequently making changes to a group of children domains, it may be more efficient to have the children defined on the parent YAML.
Domain children
Define a list of other entities as children for a domain, allowing you to represent a hierarchy of how your entities are modeled across your workspace using the x-cortex-children tag.
Domain parents
Define another entity as the parent for a domain, allowing you to represent a hierachy of how your entities are modeled across your workspace using the x-cortex-parents tag.
Note: Parents must be of type domain.
Ownership inheritance
A common use case for domains is defining ownership for the subtree of entities. Instead of defining ownership individually for every entity in your catalog, you can define ownership at the domain level and have that pass down to all of its children.
The inheritance type for each owner can be one of APPEND, FALLBACK, or NONE. If not set, inheritance is defaulted to NONE.
APPEND: This owner is appended to the list of owners for all child entities.
FALLBACK: In the case where a child has no valid owners, including fallbacks, this fallback will be assigned as the owner. Note that this only applies to a child entity down the hierarchy; it is not the fallback for the parent domain itself.
NONE: This owner owns the domain, but not necessarily any of its children (no inheritance).
Example cortex.yaml
Note: the YAML definition for a domain entity can take file names other than cortex.yaml or cortex.yml; see the GitOps example repository structure.






A webhook.
This can be done without auth or an explicit Cortex tag in the URL if you do not have access to the Cortex tag or the ability to add authentication headers.
✓
value
Value for the custom data. Anything defined after the : is the value.
✓
Custom data can be of any type, including scalars (strings, numbers, booleans), objects, and lists.
When you add custom data to an entity's YAML, you'll see the key and value pairs on an entity's Custom data page.
Custom data added via entity descriptor will display with a YAML tag.
Adding descriptions
You can add a description to data by explicitly defining it along with the key and value pairs. While key and value pairs can be defined with any terms when a description is not added, value: must explicitly be defined when a description is included.
key
Key or title for the custom data. Anything defined before the : will serve as the key.
✓
value
Value for the key; should be defined explicitly with value:
✓
description
Description of the custom data
✓
Note: While the description field is always optional, it is technically "required" to add a description to custom data.
Adding custom data via the Cortex API
You can pipe custom data directly into Cortex by POSTing to /api/v1/catalog/{tag}/custom-data where {tag}is the x-cortex-tag for a given entity.
The request body requires the following in JSON format:
See the for authentication details.
If a key has already been set through the , an API call will NOT overwrite the existing value. Instead, it will simply return the existing value.
If a key is defined in the entity descriptor, the API cannot override the key. You'll see YAML as the source value in the response body if you encounter this situation.
To explicitly overwrite values set in the YAML file, use the force=true flag as a query parameter.
Custom data added via API will display with a API tag.
Bulk upload entity keys
You can use the bulk upload endpoint to upload multiple keys for one or more entities.
PUT data in the following format to /api/v1/catalog/custom-data:
You can include multiple key and value objects for each tag. The object conforms to the same shape as the single upload API.
Learn more in Custom webhook integrations.
key
Key or title for the custom data. Anything defined before the : will serve as the key.
You can also use Cortex's to send deployment data from other services to Cortex.


View Project History: Allows Cortex to get project history.View Project: Lists issues for a project.
API token: Enter the API token you generated in Snyk.
Region: Enter the Snyk region where your data is hosted. The default region is USA.
Click Save.
CVSS score
Disclosure time
Exploit maturity
Issue ID
Language
Nearest fixed version
Original severity
Package name
Priority score
Publication time
Severity
Type
URL
Boolean characteristics:
Fixable or partially fixable
Ignored
Malicious
Definition: snyk.issues()
Example
The Scorecard's top level might include a rule to ensure that entities have a low number of Snyk issues.
To indicate progress over time and incentivize further improvement, you could set an intermediate rule with a slightly higher count of Snyk issues.
If an entity has a Snyk project set and only one or two issues, it will achieve the highest level by these standards. An entity with a Snyk project set and three or four issues will achieve the next-highest level, while an entity with a Snyk project set and five or more issues will achieve the lowest level. Entities without a Snyk project will not achieve any level, regardless of how many issues they have.
You can also write more complex rules to set more specific standards. Instead of setting a rule for a moderate number of Snyk issues, you could check that entities have no outstanding critical issues.
organization
The organizationID or organizationSlug in Snyk
✓
projectId
The projectID defined in Snyk
✓
source
Enum field that can be set to either CODE or OPEN_SOURCE to indicate the Snyk product type; defaults to OPEN_SOURCE when not set
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
Domain: Enter your Dynatrace domain necessary to access your environment, depending on whether you use managed, SaaS, or the Environment ActiveGate version.
*API token: Enter the access token you generated in Dynatrace.
Click Save.
The ID is displayed in the URL following sloexp=. For example, https://.apps.dynatrace.com/ui/.../sloexp=&slovis=
On the SLOs page, expand the details for each SLO to display the SLO ID in the URL.
Open your Cortex home page, then navigate to the service you are configuring.
In the upper right corner of the service page, click Switch to YAML.
Paste in the following text, making sure to replace slo-id-1 and slo-id-2 with the SLO IDs you obtained from the Dynatrace URL in the previous steps:
Operation
Remaining budget
SLI value
Datum
Timeseries
SLO target
Source
Thresholds
Name
Threshold
Definition: slos()
Examples
For a Scorecard focused on operational maturity, this expression can be used to make sure an entity has associated SLOs in Dynatrace:
This rule checks that there is at least one SLO is set up. While this rule makes sense in a Scorecard's first level, a rule checking the status of the SLO would make sense in a higher level:
Entities will pass this rule if all SLOs associated with it have "passing" status.

On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
View open ClickUp tasks in the dev homepage
Create Scorecards that track progress and drive alignment on projects involving your ClickUp tasks
Before getting started:
Create a ClickUp personal API token.
In Cortex, navigate to the ClickUp settings page.
Click Integrations from the main nav. Search for and select ClickUp.
Click Add configuration.
Configure the ClickUp integration form:
API token: Enter your ClickUp API token.
Click Save.
If you’ve set everything up correctly, you’ll see the option to Remove Integration in settings.
You can also use the Test configuration button to confirm that the configuration was successful. If your configuration is valid, you’ll see a banner that says “Configuration is valid. If you see issues, please see documentation or reach out to Cortex support.”
Note that mapping options will not appear in Cortex for users who have not finished user registration in ClickUp. If a user is partially registered, Cortex will filter them out of the mapping page.
By default, Cortex will use the Cortex tag (e.g. my-entity) as the "best guess" for ClickUp space, folder, or tag. For example, if your Cortex tag is my-entity, then the corresponding space, folder, or tag in ClickUp should also be my-entity.
If your ClickUp space, folder, or tag don’t cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
You can map any number of ClickUp spaces, folders, and tags to a Cortex entity. Spaces and folders can be mapped by using either ID or name.
You can find your folder ID or space ID in your ClickUp URL: https://app.clickup.com/:workspace_id/v/f/:folder_id/:space_id.
Mapping spaces by ID or name
When mapping spaces, you can use the ID or name for the space.
These blocks share the same fields:
spaces
Denotes that mapping should be based on ClickUp spaces
true
identifier
Identifier for the space; either the full ID or name
true
identifierType
Type of identifier; either ID or NAME
true
Mapping folders by ID or name
When mapping folders, you can use the ID or name for the folder.
folders
Denotes that mapping should be based on ClickUp folder
true
identifier
Identifier for the folder; either the full ID or name
true
identifierType
Type of identifier; either ID or NAME
true
Mapping by tags
Cortex also supports mapping entities to ClickUp tags.
folders
Denotes that mapping should be based on ClickUp tags
true
name
Name for the tag
true
You can also specify a ClickUp list to store all issues created via Cortex Initiatives. If Use list defined in entity YAML is toggled on in the Initiative issue creation form, Cortex will automatically create tasks in the specified list for a given entity.
If a list is not specified in an entity's YAML and Use list defined in entity YAML option is toggled on in the initiative issue creation form, Cortex will attempt to create a list in the mapped space or folder above.
Define one of these following blocks in an entity descriptor to specify a list for Initiative issues.
Specify list by ID
initiativesList
Denotes that Cortex
true
name
Name for the tag
true
Specify list by name
Cortex maps email addresses in your ClickUp instance to email addresses that belong to team members in Cortex. When identity mapping is set up, users will be able to see their personal on-call status from the developer homepage.
Note that mapping options will not appear in Cortex for users who have not finished user registration in ClickUp. If a user is partially registered, Cortex will filter them out of the mapping page.
Integrations - ClickUp
Tasks detected from your ClickUp instance will populate on the Issue tracking page in the entity's sidebar. Each row will show the following information (when available in ClickUp):
Task name (hyperlinked to task in ClickUp)
Project
Assignees
Priority
Created at
Due date
Initiatives allow you to set deadlines for specific rules or a set of rules in a given Scorecard and send notifications to users about upcoming due dates.
From the Issues tab of an Initiative, you can automatically create a ClickUp task from a failing rule.
The ClickUp integration enables Cortex to pull information about tasks into the Dev homepage. You can find open tasks assigned to you under the Issues tab.
Issues are refreshed every 5 minutes, or you can click Refresh ClickUp tasks to manually refresh issues.
With the ClickUp integration, you can create Scorecard rules and write CQL queries based on ClickUp tasks.
See more examples in the CQL Explorer in Cortex.
Initiatives allow you to set deadlines for specific rules or a set of rules in a given Scorecard and send notifications to users about upcoming due dates. You can create a ClickUp task from a failing rule in an Initiative. Learn more in Creating issues based on Initiatives.
The issue configuration will apply to all entities that meet the filter criteria. Once an entity is passing the rule, Cortex will automatically close the associated ticket.
Cortex conducts a background sync of ClickUp identities every day at 10 a.m. UTC. Pull requests and issues are refreshed every 5 minutes.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Looking for a quick introduction to Cortex? Check out the Cortex 101 video in Cortex Academy.
When you first log in to your Cortex workspace, you are prompted through the steps of configuring your account and connecting data. See the video below for a demonstration:
Before importing entities, consider your data modeling approach.
Identify the key entities that you want to represent in your Cortex catalogs.
Read more about entities and the default entity types in the Entities documentation.
If needed, create custom entity types.
Create catalogs to track and store information about the entities that make up your infrastructure.
Teams serve as both an entity representing your organization in Cortex and as owners for entities in the catalogs. Ownership is a core use case of Cortex, as organizations seek to establish clear ownership of services, data, and other entities. Ownership also drives which users will receive notifications from Cortex, including alerts for on-call changes, when an entity is re-evaluated and its Scorecard changes, and more.
Teams can be assessed via Scorecards, interact with integrations, and leverage custom data. They can also be configured in a hierarchy. In addition, team data can be tracked and analyzed in Eng Intelligence. You can manually create teams in Cortex or you can pull in teams from integrations.
Go further
Create groups to segment your entities.
Enhance your entities with custom data to provide additional context and improve searchability.
Add to entities to keep everyone informed.
Now that you’ve completed your first steps, we recommend exploring the following topics:
GitOps: You can manage your entities directly in the browser-based Cortex workspace, or you can follow a GitOps approach. We recommend starting in your Cortex workspace, then if desired, switching to GitOps before a broader rollout at your organization.
Workflows: Automate running sequential actions and development workflows based on contextual data that exist inside your workspace.
Reach out to your Customer Success Manager for more information on enabling this feature.
: If you have a unique use case for tools or work with third parties that Cortex does not have an integration with or needs to pull in data from internal systems, we offer the option to build a plugin.
: View key metrics and high-level data to gain insights into services, bottlenecks in the pull request lifecycle, incident response, and more.
Reach out to your Customer Success Manager for more information on enabling this feature.
: Learn about additional settings and features to further customize your experience: API keys, audit logs, notifications, and more.
Go further
Ready to learn more? Check out the Cortex Academy to explore courses across core product areas and build expertise on the Cortex platform!
During an incident, the entity details page allows you to quickly find the information you need all in one place: the active incident itself, who owns the entity and who is on-call, which Slack channel to communicate in, dependencies that could be affected, and the most recent deploys.
If data is not available for a field on the entity page, it will not appear in the overview. For example, if you do not have the Slack integration configured, then the "Slack channels" field will not be displayed.
Under the entity's name, the Cortex tag and the Cortex ID are displayed:
In the left sidebar of an entity, drill further into the entity's recent deploys, events, security vulnerabilities, monitoring metrics, and more, giving you the insight you need to solve an incident quickly and efficiently.
In the sidebar, click into each category for more information:
API explorer: Pulls from API documentation added to your entity.
Events: A list of recent events sourced from deploys, AWS ECS, Azure DevOps, GitHub, GitLab, Kubernetes, Opsgenie, PagerDuty, Sentry, and Snyk.
Links & docs: Documentation links you have added to the entity, along with documentation pulled from the related repository.
On-call & incidents: On-call information from , , (formerly VictorOps), and , and incidents pulled from , , , and .
Owners: See the teams who own the entity, the related Slack or Microsoft Teams channels, and a list of team members.
Learn more about how to define entity owners in .
Entity YAML: View the that defines this entity.
If you have for this entity and you have the View GitOps logs permission, this page will display the source of the YAML file and a preview of the latest GitOps log.
Scorecards: A list of any Scorecards that are in progress where this entity is being scored. In additional, see the average score, median score, and a graph showing the entity's scores over time.
Above the Scorecard section, you can choose which scores to include in calculations if the entity is in a hierarchy:
Domains: Click "This entity only" to view only the scores that apply to the domain you are viewing. Select "Include entity's children" to include both the parent domain and its child entities in the score calculations.
Entities with a custom relationship type: Click "This entity only" to view only the scores that apply to the entity you are viewing. Click "[Relationship type] only" to include both the parent and its child entities in the score calculations.
Teams: Click "This entity only" to view the scores that apply only to the team you are viewing. Click "Include entity's children" to include scores for the team, the team's children, entities owned by the team, and entities owned by the team's children.
Initiatives: A list of all active for this entity, including the Scorecard's current level and the due date of the Initiative.
Workflows: A list of that include this entity. If any Workflows are pending approval and you were designated as an approver when the Workflow was created, you will see the pending approval at the top of this page. This page also includes a list of recently run Workflows and the ability to run any related Workflows.
Under the "Connections" header, integration data for the entity is contextually grouped. When you configure integrations, data will be pulled in to the following sections on the entity details page:
CI/CD: Pulls from deploys API, Azure DevOps, Bitbucket, Buildkite, CircleCI, GitHub, and GitLab.
Custom data & metrics: Pulls from custom data and Eng Intelligence custom metrics.
Dashboard: Pulls from configured in the entity's YAML file for , , and .
Error tracking: Pulls from , , and .
Environments: Pulls from and .
Issue tracking: Pulls from , , , , and .
Monitoring: Pulls from , , , , , , , (formerly SignalFX), and .
Packages: Pulls from the and any packages automatically discovered from your configured git repositories.
Repository: Pulls from , , , and .
Integration settings: This page lists the integrations that are enabled and connected for this entity.
Under the "Plugins" header, see any plugins in your workspace that are relevant to this entity.
Learn more about entities in Managing entities.
When a dependency deprecates its API or makes backwards incompatible changes, Cortex surfaces these issues via these methods:
Breaking API changes are listed in your Cortex workspace under Settings > Breaking API changes.
Cortex attempts to automatically make comments on PRs containing breaking OpenAPI changes that have downstream dependencies that Cortex knows about.
If a breaking change is merged to the default branch, Cortex alerts dependency owners via Slack that a breaking change was merged.
Cortex can automatically discover dependencies from your integrations:
You can define dependencies manually via an entity's YAML descriptor, via the Cortex UI (if UI editing is enabled), or via the API.
Your user or API key need the Edit entities permission.
Define dependencies in the Cortex UI
Navigate to the entity where you need to define a dependency.
In the upper right corner of the entity details page, click Configure entity.
Click the Hierarchy tab.
In the Dependencies block, click +Add entity.
In the dropdown menu, choose an entity.
Optionally, select an endpoint.
In order for an endpoint to populate in this dropdown, it must first be defined as a path in the entity's YAML file. See below.
Click Add.
Set an endpoint for a dependency
Before you can select an endpoint from the dropdown when manually defining a dependency, that endpoint must be defined as a path in the entity's YAML file. See the example below:
In the UI, the paths will appear in the Endpoint dropdown:
Define dependencies in the entity descriptor
The x-cortex-dependency field allows you to define a list of outgoing dependencies. A dependency should be directed towards an outgoing service or resource, or more granularly, to a specific endpoint of that entity.
Define dependencies via the API
See the for authentication details.
YAML is the source of truth. If a dependency has already been set through the cortex.yaml, the API will return an error.
Endpoints are optional. A dependency optionally references an endpoint (method and path) of the callee, and this must already be defined in the callee's cortex.yaml within the paths
Cortex syncs AWS dependencies every day at 8:00 a.m. UTC. All other dependencies sync at 12:00 a.m. UTC.
You must have the Enable entity dependency discovery permission to manually sync dependencies.
If you need to sync dependencies manually:
Navigate to Tools > Relationship graphs.
In the upper right corner of the page, click the menu icon, then click Sync dependencies.
When leveraging multiple dependency sources (such as Datadog and a catalog entity's YAML), all the sources will be merged together and deduplicated.
For example, if an entity YAML indicates X->Y and Datadog indicates X->Y and X->Z, we will have two edges presented (X->Y and X->Z).







Microsoft Teams is a communication and collaboration platform designed to promote greater productivity through messaging and file-sharing tools.
Integrating Microsoft Teams with Cortex allows you to:
Quickly find the relevant MS Teams channel to communicate with the right team, allowing for easier collaboration on projects and faster communication during an incident
MS Teams channels appear in the "Owners" block on entity details pages.
Receive actionable directly in MS Teams for Scorecard changes, upcoming Initiatives, weekly summaries of entity performance, and more
Create that enforce standards such as having an MS Teams channel set for projects
This page describes how to integrate Microsoft Teams with Cortex cloud. If you're using a self-managed Cortex instance, you'll need to follow a manual configuration process to use Cortex's app for Microsoft Teams. Follow the .
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Microsoft Teams.
Click Add configuration.
In the side panel, click Connect account via Microsoft Teams OAuth
After authenticating, you will be redirected to the Microsoft Teams integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Microsoft Teams was configured properly.
On the in Cortex, click the link.
In AppSource, click Get it now. You will be redirected to a page where you can choose whether to download a desktop app or use the web app.
MS Teams admins can configure a setup policy for Cortex, can choose whether to automatically download the Cortex app into the personal Teams environments for users, and can choose to pin the app to make it more easily accessible.
If admins do not add a policy to install the Cortex app, then users will need to download the app during setup.
Navigate to the Teams under Teams app > Setup policies.
Click Add to start configuring a setup policy for the Cortex app.
After configuring a policy, navigate to the Installed apps section. Add the Cortex app here.
Cortex does not automatically discover MS Teams channels based on a so you must as described below.
In order to use this integration's functionality, your MS Teams channels need to be associated with entities in Cortex. Cortex does not automatically discover channels for MS Teams, so you must define them in the .
To associate a Microsoft Teams channel with an entity, define a x-cortex-microsoft-teams block in an as shown in the example below.
Defining a Teams channel will provide in Cortex.
: After MS Teams channels are defined in an entity's YAML, MS Teams channels will appear at the top of an entity's overview page in the MST channels block. Channels are also listed in the "Owners" page in an entity's sidebar. You can click any channel name to go directly to that channel in Microsoft Teams.\
You can write CQL queries and Scorecard rules based on Microsoft Teams channels. Learn more under .
After configuring the Microsoft Teams integration, you can choose whether to allow Microsoft Teams notifications for your workspace.
In Cortex under Settings > Notifications, an admin or a user with the Configure workspace notification settings permission can enable or disable the option to receive notifications via MS Teams for each type of notification. Users can also adjust their to control which notifications they receive via MS Teams.
Notifications are . DMs and channel notifications are sent from the Cortex app.
User-based notifications are sent to users via a DM from the Cortex app.
Team-based notifications are sent to the MS Teams channel associated with a team.
Entity-based notifications are sent to the MS Teams channel associated with an entity.
Learn more about notifications in the .
With the Microsoft Teams integration, you can create Scorecard rules and write CQL queries based on Microsoft Teams channels.
See more examples in the in Cortex.
We will retain basic Microsoft Teams metadata like user IDs for the period necessary to fulfill the purposes outlined in our unless a longer retention period is required or permitted by law, or where the Customer Agreement requires or permits specific retention or deletion periods.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Relationship types allow you to define, manage, and visualize relationships between entities within your Cortex workspace, ensuring your organization's structures and dependencies are accurately represented.
A relationship type defines how two entities relate to either other, and constrains the types of entities that can be the source and destination entities within the relationship.
Cortex provides multiple options for defining a relationship:
Entity relationship: As described on this page, you can customize a relationship type (hierarchical or cyclical) between any entity type.
Team hierarchy: You can define a hierarchical relationship between team entities. Teams can have over other entities. Learn more in .
Domain hierarchy: You can define a hierarchical relationship between domain entities. You can also configure inheritance; the owner of an entity can be inherited from entities higher in the domain hierarchy. Learn more in .
Note that you should not create custom relationship types to represent ownership; .
To view all relationship types, go to Catalogs > All entities then click the .
To view the details of a specific relationship type, click its name from the list.
If an entity is part of a relationship, you can view this information on its . Click Relationships in the left sidebar to see the different relationship types that the entity belongs to.
In the example entity below, there are three destination entities in an "App Components" relationship:
Create relationship types in the Cortex UI
Navigate to Catalogs > All entities then click the .
In the upper right corner, click Create > Create new relationship type. \
Configure the details and entity types:
You can create Scorecard rules and write CQL queries based on entity relationships.
See more examples in the in Cortex.
Atlassian is deprecating the Opsgenie product and encouraging their customers to migrate to Jira Service Management. Read more about moving from Opsgenie to Jira Service Management on .
Cortex is actively working on developing an integration with Jira Service Management.
is an alert and on-call management platform from Atlassian.
Integrating Opsgenie with Cortex allows you to:
claude mcp add --transport http cortex-remote https://mcp.cortex.io/mcp --header "Authorization: Bearer <CORTEX_TOKEN>"{
"servers": {
"cortex": {
"url": "https://mcp.cortex.io/mcp",
"type": "http",
"headers": {
"Authorization": "Bearer <CORTEX_TOKEN>"
}
}
}
}{
"mcpServers": {
"cortex": {
"type": "http",
"url": "https://mcp.cortex.io/mcp",
"headers": {
"Authorization": "Bearer <CORTEX_TOKEN>"
}
}
}
}x-cortex-link:
- name: Human Readable Name
type: runbook
url: https://cortex.io
description: Optional Descriptionopenapi: 3.0.1
info:
title: Payments
description: This is my cool domain.
x-cortex-tag: payments-domain
x-cortex-type: domainopenapi: 3.0.1
info:
title: Payments
description: This is my cool domain.
x-cortex-tag: payments-domain
x-cortex-type: domain
x-cortex-children:
- tag: child-domain-1
- tag: child-service-1
- tag: child-resource-1openapi: 3.0.1
info:
title: Payments
description: This is my cool domain.
x-cortex-tag: payments-domain
x-cortex-parents:
- tag: parent-domain-1
- tag: parent-domain-2openapi: 3.0.1
info:
title: Payments
description: This is my cool domain.
x-cortex-tag: payments-domain
x-cortex-type: domain
x-cortex-owners:
- type: GROUP
name: cortexapps/engineering
provider: GITHUB
inheritance: APPENDopenapi: 3.0.1
info:
title: Chat
description: Chat domain.
x-cortex-tag: chat-domain
x-cortex-type: domain
x-cortex-children: # children can be of type service, resource, or domain
- tag: chat-service
- tag: chat-database
x-cortex-parents: # parents can be of type domain only
- tag: payments-domain
- tag: web-domain
x-cortex-owners:
- type: group
name: Support
provider: OKTA
description: Support Team
x-cortex-slack:
channels:
- name: support-team
notificationsEnabled: true
description: This is a description for the support-team Slack channel # optional
x-cortex-oncall:
pagerduty:
id: ASDF2345
type: SCHEDULE
x-cortex-apm:
datadog:
monitors:
- 23456x-cortex-custom-metadata:
key-example: value-example
arbitrary-custom-data: hippocampus
regions-of-brain:
value: 3
description: cerebrum, cerebellum, brainstem
cognition: truex-cortex-custom-metadata:
regions-of-brain:
value: 3
description: cerebrum, cerebellum, brainstem
brain-hemispheres:
value: 2
description: The brain has a left and a right hemisphere.x-cortex-snyk:
projects:
- organization: org-name
projectId: 01234567-e65f-4b7b-a8b1-5b642894ec37
source: CODEsnyk != nullsnyk.issues() < 3snyk.issues() < 5snyk.issues(severity=["CRITICAL"], fixability=["FIXABLE"]) <= 0x-cortex-apm:
dynatrace:
entityIds:
- mock-service-id-1
- mock-service-id-2x-cortex-apm:
dynatrace:
entityNameMatchers:
- "foo.*"x-cortex-slos:
dynatrace:
- id: slo-id-1
- id: slo-id-2slos().length > 0slos().all((slo) => slo.passing)x-cortex-issues:
clickup:
spaces:
- identifier: 123456789
identifierType: IDx-cortex-issues:
clickup:
spaces:
- identifier: My Space
identifierType: NAMEx-cortex-issues:
clickup:
folders:
- identifier: 123456789
identifierType: IDx-cortex-issues:
clickup:
folders:
- identifier: my-folder
identifierType: NAMEx-cortex-issues:
clickup:
tags:
- name: tag a
- name: tag b
- name: tag cx-cortex-issues:
clickup:
initiativesList:
id: 12345x-cortex-issues:
clickup:
initiativesList:
name: Cortex Initiative IssuesPinnable
Upgradable
Select CUSTOM if using a dedicated instance.

clickup.tasks().filter((task) => task.assignees.length < 1).length < 5clickup.tasks(priorities=["Urgent"], tags=["security"]).length == 0None: Select this option if you do not want to configure inheritance. The owner will own the domain you are creating, but will not be configured as an appended or a fallback owner.
IP allowlist: You can use the IP allowlist to control where your Cortex workspace can be accessed from.
Connecting project tracking tools allows you to link entities with their roadmaps, tickets, and initiatives.
Communication: Slack, Microsoft Teams
Configuring a communication provider allows you to receive timely notifications and collaborate seamlessly with team members.
Configure your Scorecard, making any modifications necessary.
For in-depth instructions on creating Scorecards, see Creating and editing Scorecards.
When you are finished, click Save Scorecard.

path
The actual endpoint this dependency refers to
Required if method is present
description
A description of the dependency.
Yes
metadata
JSON metadata tags for the relationship. Supports arbitrary objects.
Yes
For all requests method or path are optional, however if one is present the other must also be present.
When interacting with an existing dependency, the method and path must be specified correctly to identify it.
callerTag
The tag of the caller.
No
calleeTag
The tag the caller depends on.
No
method
HTTP method if depending on a specific endpoint
Required if path is present
path
The actual endpoint (as defined in the OpenAPI file) the caller depends on
Create a dependency
POST /api/v1/catalog//dependencies/?method=&path=
Retrieve a dependency
GET /api/v1/catalog//dependencies/?method=&path=
Update a dependency
PUT /api/v1/catalog//dependencies/?method=&path=
PUT replaces entire object. The request body is considered a modified version of the already existing entity. Leaving a field out of the JSON will be interpreted as null.
Delete a dependency
DELETE /api/v1/catalog//dependencies/?method=&path=
Bulk create or update dependencies
PUT /api/v1/catalog/dependencies
:::caution PUT replaces entire object The request body is considered a modified version of the already existing entity. Leaving a field out of the JSON will be interpreted as null. :::
tag
The tag of the entity this entity depends on, i.e. the callee. See x-cortex-tag
No
method
HTTP method if depending on a specific endpoint
Required if path is present



In the pop-up window, follow the prompts to log in to your Microsoft account. The user configuring the integration must accept the permissions listed below:
TeamMember.Read.Group
Enables Scorecard rule for Teams
Teamwork.Migrate.All
Enables notifications for users/team channels
MS Teams admins can also apply the policy to specific users in the Teams admin center under Users > Manage Users.
To pin the app, follow Microsoft's instructions on pinning apps.
Example
You can use this expression in the Query builder to identify teams missing a Microsoft Teams channel:
Team name
Definition: microsoftTeams.members().length
Example
For a Scorecard focused on team operations, you can verify that the Microsoft Teams channel has at least one member in it:
Organization.Read.All Directory.Read.All Organization.ReadWrite.All Directory.ReadWrite.All
Enables Cortex to get all organizations and fetch all repos for the import page
User.Read.All User.ReadWrite.All Directory.Read.All Directory.ReadWrite.All
Pulls Teams users into Cortex
ChannelSettings.Read.Group
Enables notifications
Team.ReadBasic.All
name
Microsoft Teams channel name (exact match)
✓
teamName
Team name (exact match)
✓
description
Description for the Teams channel
notificationsEnabled
Boolean to enable/disable notifications


On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
Enables notifications to teams
Monorepo
Mapping multiple services to a single repository.
Repository
Service
Service to endpoint
Associating services with their endpoints.
Service
Endpoint
Data center modeling
epresenting data centers and their relationships to other infrastructure components.
Data center
Component
Name: Enter a name for the relationship type.
Identifier: Enter a unique identifier, used to specify this relationship in YAML definitions for this relationship type.
Description: Add a description of the relationship to help others understand its purpose.
Create relationship type catalog: Enable this option to create a catalog for this relationship type.
Source entity types: Search for and select the entity types which will be the source for this relationship. Selecting no entity type means that all entity types are available as sources.
You can also customize the singular and plural wording of the entity types and the cardinality.
Destination entity types: Search for and select the entity types which will be the destination for this relationship. Selecting no entity type means that all entity types are available as destinations.
You can also customize the singular and plural wording of the entity types and the cardinality.
Configure the relationship constraints:
Architecture: If you are configuring hierarchical data, such as an org chart, we recommend choosing Acyclical. If you are configuring graph-like data, such as dependencies, we recommend choosing Cyclical.
Definition location: Configure where relationships can be defined — from destination entities, from source entities, or from either.
Configure metadata inheritance.
Enable the Ownership toggle to configure inheritance for the relationship type, then select how metadata will be inherited:
Fallback: This option uses the source's data only if the destination does not have anything defined.
Append: This option appends the source's data to the destination, even if it already has data defined.
Learn more about inheritance in .
Click Create.
Create relationship connections between entities in the UI
After creating the relationship type, you can configure connections between entities in a relationship. You can do this via the entity descriptor or in the UI, as described below:
Navigate to an entity details page. In the upper right corner, click Configure entity.
Click the Relationships link on the left.
At the top of the Relationship Type section, click the dropdown to select which relationship type you are configuring connections for.\
After selecting the relationship type, you can search for and select entities in the Sources dropdown and in the Destinations dropdown.
At the bottom of the page, click Save changes.
Create relationship connections between entities in the entity descriptor
Relationship types must be created in the Cortex UI or via the API. You can configure relationship connections between entities in the entity YAML.
In a source entity's YAML, you can use the x-cortex-relationships tag to define its destination entities.
In the example below, a source entity's YAML has a defined relationship type called app-components and has destination entities production-ui and backend-app.
The relationship between entities in Cortex is based on the relationship being defined in the entity's YAML file; Cortex does not set hierarchies or relationships based on a YAML file's location in your repository.
Create relationship types via the API
Documentation is coming soon for managing relationship types via the Cortex API. Please reach out to your Cortex Customer Success Manager with any questions.
Make any necessary changes, then at the bottom of the page, click Save.
Repository
Mapping services to repositories to view the hierarchy of repos and the services they contain. For example, a service is linked to its code repository.
Service
Repository
Cloud account to resource
Associating cloud accounts (like AWS, Google Cloud Project, or Azure subscription) with their respective resources (such as EC2 instances or other cloud resources).
AWS account
GCP
Azure subscription
AWS resources (e.g., EC2)
Google Cloud resources
Azure resources
Service to environment
Linking services to their deployment environments.
Service




Environment
Pull in on-call rotation data and escalation policies
The on-call user or team will appear in the Current On-call block on an entity's details page.
You can also view on-call information on an entity page in its side panel under Integrations > On-call.
View alerts from Opsgenie in an entity's event timeline
Create Scorecards that track progress and drive alignment on projects involving your on-call schedules and alerts
Before getting started, create an Opsgenie API key with the following permissions:
Read
Configuration Access
In Cortex, navigate to the Opsgenie settings page:
Click Integrations from the main nav. Search for and select Opsgenie.
Configure the Opsgenie integration form:
Subdomain: Enter the subdomain assigned to your Opsgenie instance.
API key: Enter your Opsgenie API key.
Use European service region: Optionally, toggle this setting on to enable the EU region of Opsgenie.
Click Save.
By default, Cortex will use the Cortex tag (e.g. my-entity) as the "best guess" value for the backend and service tags on your alerts. For example, if your alert in Opsgenie has the tag backend:my-entity, the alert will be automatically associated with the entity in Cortex with a unique identifier of my-entity.
If your Opsgenie tags don’t cleanly match the Cortex tag, or you use different identifying tags, you can override this in the Cortex entity descriptor.
type
Type of alert (in this case, opsgenie)
✓
tag
Type of tag in Opsgenie (e.g. backend)
✓
value
Alert in Opsgenie (e.g. my-entity-override-tag)
✓
For example, for the tag different-tag:my-entity-override-tag, the entity descriptor would have different-tag in the tag field and my-entity-override-tag in the value field.
You can add a list of tags to use for lookup. Cortex will use an OR operator when querying Opsgenie (e.g. backend:my-entity OR service:another-value).
The value field also supports wildcards (e.g. value: my-entity*).
Adding a schedule
You can define the following block in an entity descriptor to add an Opsgenie schedule. Cortex supports adding a schedule by ID or UUID. You can add one schedule per entity.
The UUID for the schedule can be found in URL when viewing schedule details by clicking on the schedule name under who is on-call.
type
Opsgenie component being added (in this case, SCHEDULE)
✓
id
Schedule ID or UUID
✓
type
Ownership type (in this case, group)
✓
name
Name of the team defined in Opsgenie (**case-sensitive)
✓
provider
Identity provider (in this case, OPSGENIE)
✓
description
Description for the team, to be displayed in Cortex
Cortex maps email addresses in your Opsgenie instance to email addresses that belong to team members in Cortex. When identity mapping is set up, users will be able to see their personal on-call status from the developer homepage.
After setting up the integration, Opsgenie information will appear in several places across Cortex.
On an entity details page, current on-call information from Opsgenie will display in the On-call block.
Escalation policy, the level associated with the policy, and other on-call information will also appear in the entity's sidebar in the "On-call & incidents" page. Owners assigned to each level will also be hyperlinked to the user or team page in Opsgenie.
Click Events in an entity's sidebar to view recent events pulled in from Opsgenie.
The Opsgenie integration enables Cortex to pull on-call information into the on-call block on the Dev homepage. On-call data from Opsgenie is refreshed every 1 minute.
With the Opsgenie integration, you can create Scorecard rules and write CQL queries based on Opsgenie on-call schedules and alerts.
See more examples in the CQL Explorer in Cortex.
Ownership CQL
Cortex performs the following background jobs:
Ownership: A sync for Opsgenie teams every day at 9 a.m. UTC.
Identity mapping: A sync for Opsgenie identities every day at 10 a.m. UTC.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
key
string
Key or title for the custom data
✓
value
object
Value for the custom data
✓
description
string
Description of the custom data






Amazon Web Services (AWS) provides on-demand cloud computing platforms and APIs.
Integrating Cortex with AWS allows you to:
Track AWS entities in the catalog
Automatically discover and track ownership of AWS entities and dependencies
You can also enable auto-import of any discovered entities of known types.
Create that track progress and drive alignment on projects involving your AWS resources
If you are on a self-hosted Cortex instance, see the page.
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select AWS.
Click Add configuration.
In the modal, the JSON configuration, Cortex AWS account ID, and External ID are displayed. In the configuration side bar instructions, you will also see the option to copy a starting "Read Only Access" JSON policy. Keep this browser window open, as you will need these in the next steps.
For each account:
Log in to your AWS Management Console and open the .
Click Policies, then choose Create policy.
Switch to the JSON editor. In Cortex while configuring AWS, copy the JSON "Read Only Access" starting policy that appears in the in-app instructions. Paste it into the JSON editor.
See the AWS documentation for more information: .
This section is specific to cloud-based Cortex accounts. If you are on a self-hosted Cortex instance, please see the AWS account setup guide for self-hosted Cortex.
In AWS, navigate to Roles > Create Role.
For the trusted entity type, select Another AWS account.
In the Account ID field, enter the Cortex AWS account ID that was displayed in Cortex in the earlier steps.
Click Require External ID, then enter the Cortex external ID that was displayed in Cortex in the earlier steps.
Note that if you use multiple AWS accounts, they will share a common rotatable externalId.
Navigate back to the browser window containing your .
Configure the AWS integration form:
Account ID: Enter the AWS account ID you obtained in the previous steps.
IAM role: Enter the role name you obtained in the previous steps.
In your in Cortex, Cortex will pull all the types you included in the IAM policy into the Cloud Control types dropdown.
If any resource types do not appear in the list, ensure that cloudformation:ListTypes, cloudformation:ListResources, and cloudformation:GetResource are added to the IAM policy so Cortex can pull the list of all available types from AWS.
To select your cloud control types:
In the Cloud control types field, select the types you want Cortex to discover.
If is enabled, then these types will automatically be imported into Cortex.
If you later need to remove any auto-imported cloud control types, see .
If the type you're looking to import is in the list below, please reach out to to submit a feature request.
The following Cloud Control types are not currently supported:
You can configure automatic import from AWS:
In Cortex, navigate to the .
Next to Auto import from AWS, Azure, and/or Google Cloud, click the toggle to enable the import.\
If you do not have automatic import enabled, you can .
By default, Cortex will search for resources across all AWS regions, but you can limit that to specific regions in the .
See the for instructions on importing entities.
Cortex automatically discovers dependencies between your services and resources by scanning for resources with specific AWS tags. By default, a service will have dependencies on any Cortex resource that has a corresponding AWS resource with key = "service" and tag value = the service's Cortex tag.
In Cortex under the , you can customize the tag key names. Expand the Dependencies sync from AWS section, then select tags from the dropdown menu. Note that an AND operator is used when you select multiple tags; the resource will need to have all specified tags in order to be recognized by Cortex.
If you do not specify tag names, Cortex will use "service" as the key name.
Cortex syncs AWS tags daily at 8 a.m. UTC. To manually refresh the tags, navigate to the in your workspace, click the menu in the upper right corner, then click Sync dependencies.
Use key/value pairs in the entity descriptor for discovery
You can also use explicit tag key/value pairs in the x-cortex-dependency block for AWS dependency discovery. Instead of making a service depend on a resource based on service tags, Cortex will make a service depend on a resource if any of the resource's AWS tags match the explicitly defined key/value pairs in the service's x-cortex-dependency block. For example, the service below will have dependencies on any AWS resource with tag (key = aws:cloudformation:my-key-1, value = arn:aws:cloudformation:my-region:my-value-1) or tag (key = aws:cloudformation:my-key-2, value = arn:aws:cloudformation:my-region:my-value-2).
For more information on dependencies, see the .
Cortex can automatically discover ownership for your AWS resources. To enable this, make sure that your AWS resources have a tag matching the x-cortex-tag of the corresponding Cortex team and enable the “Sync ownership from AWS” toggle in the Settings page. By default, we look for the owner tag. You can also customize the tag key name.
Cortex syncs ownership from AWS every day at 6 am UTC.
We recommend for the fastest and most efficient experience connecting your data. If you need to manually edit entity descriptors, see the information below.
You can associate a Cortex entity with one or more AWS entities. For certain AWS resource types, Cortex will display those AWS entities' metadata on the Cortex entity page.
Multiple ECS services on a single entity
You can associate a Cortex entity with multiple ECS services.
If you are using the Cloud Control resource types, use the format below:
If you are not using Cloud Control types or if you imported your entity prior to Cortex supporting Cloud Control types, you can use the format shown below:
The values for clusterArn and serviceArn are defined in .
Cortex will pull recent changes from your AWS environment into the . Here, you can find new entities in AWS that have not been imported into the catalog - these will have the tag New AWS Resource - as well as entities in the catalog that no longer exist in AWS - these will have the tag AWS Resource Not Detected.
The following keys are supported when searching for your AWS entities in Cortex under Catalogs > All Entities:
aws-account-id - Account ID number
aws-account-name - Account alias
aws-region - AWS region of the resource
aws-type:"AWS::EC2" AND aws-region:"us-west": Search for entities of category EC2 in the any of us-west regions
aws-account-id: "234512324": Search for all entities from the account 234512324
aws-name:"aws-identifier-of-resource" AND aws-account-name:"test-account": Search for entity with identifier aws-identifier-of-resource in the account with alias test-account
With the AWS integration, you can create Scorecard rules and write CQL queries based on AWS resources.
See more examples in the in Cortex.
Cortex conducts the following background syncs for AWS:
Ownership sync daily at 6 a.m. UTC
AWS tag sync (dependencies) daily at 8 a.m. UTC
You can via the Relationship Graph.
Integration details daily at 10 a.m. UTC
If you want to remove any of the cloud control types after importing them: Disable the setting, remove the cloud control types from your , then enable . This will cause the removed cloud control types to be archived during the next sync.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Datadog is an application performance monitoring platform that provides real-time observability into entities, servers, databases, and tools, providing developers with a comprehensive understanding of their infrastructure as well as the ability to identify areas for improvement.
Cortex is uniquely equipped to augment Datadog's tools, providing greater visibility into your entities. In this guide, you'll learn how to set up the Datadog integration to pull in services and metrics for entities:
Monitors
SLOs
Dependencies
Before getting started, make sure you have created the following:
You can create this in Datadog under Organizational Settings > Applications Key.
Include the following scopes:
monitors_read
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Datadog.
Click Add configuration.
Configure the Datadog integration form:
After saving your configuration, you are redirected to the Datadog integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Datadog was configured properly.
The Datadog integration has multi-account support. You can add a configuration for each additional by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the Datadog page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.How to connect Cortex entities to Datadog
By default, Cortex will use the (e.g. my-entity) as the "best guess" for Datadog tag. For example, if your Cortex tag is my-entity, then the corresponding tag in Datadog should also be my-entity.
If your Datadog tags don’t cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
See the for instructions on importing entities.
You can use service tags to connect Datadog services to Cortex entities.
These tags are used to "discover" your monitors and SLOs. Cortex will find monitors and SLOs by querying tag:value OR tag:value2 ...
If you want to hard code and/or override discovery, you can define a monitor or SLOs block in the entity descriptor, as described below.
Monitors and SLOs
Adding monitors let you see information about their current status directly from a catalog - via the Monitors column - and under the Operations section of an entity page. You can find your monitors from Datadog's .
The ID of a monitor is found in the URL when you click on a monitor in your Datadog dashboard i.e., https://app.datadoghq.com/monitors/****.
Like monitors, Datadog SLOs can be found in the Operations section of an entity page. You can find the SLOs for your instance on Datadog's .
The ID for the SLO can be found in the URL when you click on an SLO in the Datadog dashboard. For example, https://app.datadoghq.com/slo?slo_id=****&timeframe=7d&tab=status_and_history.
Monitors and SLOs have the same field definitions.
Cortex automatically syncs dependencies from Datadog's , using the entity identifier (x-cortex-tag) to map entities found in the Service Map.
The relationships Cortex discovers through the integration will feed directly into the , so you can easily visualize the connections between your entities.
If you have two entities - for example, entity-one and entity-two - that have a dependency edge in Datadog's Service Map, both entities should exist in Cortex with the same identifiers ().
You can override this by where tag = entity and value = entity name in Datadog Service Map.
If the Cortex tag does not exactly match the entity identifier in Datadog, the dependencies will not automatically sync. You can override automatic discovery by defining values in the entity descriptor.
You can connect an APM service for dependency mapping in the entity descriptor:
With the Datadog integration, you'll be able to find monitors and SLOs on an entity's home page. High-level information about monitors and SLOs appears in the Overview tab.
Click Monitoring in the entity's sidebar to see more detailed data about both monitors and SLOS. Both sections display tags for Pass, Fail, Warning, and No Data for each monitor or SLO.
The SLOs column shows each SLO, its target(s), the current value for that entity, its status. and the period of time the SLO is being calculated for. For example, if the time listed is "7 days ago," then the SLO is looking at the time range starting 7 days ago to now..
The Monitors column shows the title for each monitor, its query (if available), and its status.
Clicking any block with a nonzero value will open a modal with more detailed information. The monitor modals will list all monitors with the applicable status. The SLO modals will also display targets for each SLO that is passing or failing.
With the Datadog integration, you can create Scorecard rules and write CQL queries based on Datadog metrics, monitors, and SLOS.
See more examples in the in Cortex.
You can read more about Datadog's and in their docs.
Cortex will pull recent changes from your Datadog environment into the . Here, you can find new entities in Datadog that have not been imported into the catalog - these will have the tag New APM Resource - as well as entities in the catalog that no longer exist in Datadog - these will have the tag APM Resource Not Detected.
The dependency sync runs automatically each day at 12 a.m. UTC, and can be run manually via the in the .
Can I set a Scorecard rule to monitor Datadog monitors/SLOs based on tags?
Yes, you can that allow Cortex to discover your SLOs and monitors, and use these tags in Scorecard rules.
How does Datadog work with other dependency sources?
When leveraging multiple dependency sources such as Datadog and a catalog entity's YAML, all the sources would be merged together and Cortex will de-duplicate the dependencies.
For example, if an entity YAML indicates X → Y and Datadog indicates X → Y and X → Z, the entity will display two edges presented as X → Y and X → Z.
is an open-source platform that empowers developers to write clean and safe code by continuously inspecting code quality and reviewing for bugs, vulnerabilities, and code duplication.
Integrating SonarQube with Cortex allows you to:
Pull in code smells, bugs, code coverage, vulnerabilities, and custom metrics on
Create that track progress and drive alignment on projects involving your SonarQube projects
This integration is supported for both SonarQube Server and SonarQube Cloud.
An entity is an object that represents a software construct. A defined collection of entities is known as a . All entities are represented in YAML, can pull in data from integrations, and can be .
Each entity has its own page that centralizes data related to it, allowing you to quickly access the information you're looking for. Learn more in the documentation.
Want to learn more? Check out the Cortex Academy course on , available to all Cortex customers and POVs.
openapi: 3.0.1
info:
title: Endpoint Example Service
description: "This is an example"
x-cortex-tag: endpoint-example-service
x-cortex-type: service
paths:
/hello/world:
get:
description: Some description
requestBody:
description: optional
responses:
"200":
description: optional
deprecated: false
/another/path:
put:
deprecated: falseinfo:
x-cortex-dependency:
- tag: braavos
method: GET
path: /2.0/users/
description: ensure user has payment information configured
metadata:
tags:
- billing
- identity
prod: true{
"callerTag": "my-service",
"calleeTag": "braavos",
"path": "/2.0/users/",
"method": "GET",
"description": "ensure user has payment information configured",
"metadata": {
"tags": ["billing", "identity"],
"prod": true
}
}{
"description": "ensure user has payment information configured",
"metadata":
}{
"description": "ensure user has payment information configured",
"metadata":
}{
"values": {
"my-service": [
{
"tag": "braavos",
"path": "/2.0/users/",
"method": "GET",
"description": "ensure user has payment information configured",
"metadata":
}
],
"my-other-service": [
{
"tag": "my-service",
"path": "/1.0/widget/",
"method": "GET",
"description": "get widget",
"metadata":
}
]
}
}x-cortex-microsoft-teams:
channels:
- name: team-engineering
teamName: engineering
description: This is a description for the engineering channel in Teams.
notificationsEnabled: truemicrosoftTeams != nullmicrosoftTeams.channels().length < 1microsoftTeams.members().length > 0 x-cortex-relationships:
- type: app-components
destinations:
- tag: production-ui
- tag: backend-appentity.destinations(relationshipType = "my-relationship").length > 0entity.sources(relationshipType = "my-relationship").length > 0oncall != nulloncall.numOfAlerts(lookback=duration("P1M"),query="status: open").length < 2oncall.numOfAlerts(lookback=duration("P1M"),query="priority: P1").length < 2oncall.numOfEscalations() >= 2ownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)ownership.teams().all(team => team.description != null and team.isArchived == false)x-cortex-alerts:
- type: opsgenie
tag: different-tag
value: my-entity-override-tagx-cortex-oncall:
opsgenie:
type: SCHEDULE
id: Cortex-Engineeringx-cortex-owners:
- type: group
name: My Opsgenie Team
provider: OPSGENIE
description: This is a description for this owner{
"values": {
"<entity-tag>": [
{
"key":"example-key",
"value":"example value",
"description":"A description of these data."
}
],
"<another-entity-tag>": [
{
"key":"example",
"value":{
"my-data":"my-value",
"complex": "data",
"v": 0
}
}
]
}
}



If you choose to configure this manually, rather than using the starting policy provided, insert a valid IAM policy depending on the resource types you'd like to import. For example, if you want to import resources of type AWS::IAM::role, we'll need to have permission to iam:ListRoles, iam:ListAttachedRolePolicies, iam:GetRole, and iam:ListRolePolicies.
For manual configurations, make sure to add the cloudformation:ListTypes, cloudformation:ListResources, and cloudformation:GetResource permissions so that we can pull the list of types available from AWS.
Click Review Policy, enter a name, then click Create Policy.
Click Next.
Select your newly created policy, and click Next.
Enter a name for your role. Optionally, configure tags. When you are finished, click Create Role.
Search for your new role in the list and copy its name. You will need this in the next steps.
In the upper right corner of AWS, click your name. In the dropdown that appears, copy your AWS account ID. You will need these in the next steps.
Click Save.
aws-type - AWS type of the resourceaws-name - AWS name of the resource
aws-identifier - The primary identifier of a resource
aws-secondary-identifier - The secondary identifier of a resouce



On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
oncall.details().type =! "schedule"oncall.details().id.matches("Legacy*") == falseAWS::ApiGateway::DocumentationVersion
AWS::ApiGateway::Step
AWS::CloudFormation::ResourceVersion
AWS::CustomerProfiles::Integration
AWS::CustomerProfiles::ObjectType
AWS::EC2::TransitGatewayMulticastGroupMember
AWS::EC2::TransitGatewayMulticastGroupSource
AWS::ECS::TaskSet
AWS::Glue::Attach::SchemaVersion
AWS::Glue::Attach::SchemaVersionMetadata
AWS::IoTSiteWise::AccessPolicy
AWS::IoTSiteWise::Dashboard
AWS::IoTSiteWise::Project
AWS::Kendra::DataSource
AWS::Kendra::Faq
AWS::MediaConnect::FlowEntitlement
AWS::MediaConnect::FlowOutput
AWS::MediaConnect::FlowSource
AWS::MediaConnect::FlowVpcInterface
AWS::MediaPackage::Asset
AWS::MediaPackage::PackagingConfiguration
AWS::NetworkFirewall::LoggingConfiguration
AWS::QuickSight::Analysis
AWS::QuickSight::Dashboard
AWS::QuickSight::DataSet
AWS::QuickSight::DataSource
AWS::QuickSight::Template
AWS::QuickSight::Theme
AWS::RDS::DBProxyTargetGroup
AWS::S3Outposts::AccessPoint
AWS::S3Outposts::Bucket
AWS::SSO::Assignment
AWS::SSO::InstanceAccessControlAttributeConfiguration
AWS::SSO::PermissionSetx-cortex-dependency:
aws:
tags:
- key: my-key-1
value: my-value-1
- key: my-key-2
value: my-value-2
- key: "aws:cloudformation:my-key-1"
value: "arn:aws:cloudformation:my-region:my-value-1"
- key: "aws:cloudformation:my-key-2"
value: "arn:aws:cloudformation:my-region:my-value-2"x-cortex-infra:
aws:
cloudControl:
- type: AWS::RDS::DBInstance
region: us-west-2
accountId: "123456123456"
identifier: rds-examplex-cortex-infra:
aws:
cloudControl:
- type: AWS::ECS::Service
region: us-west-2
accountId: "123456123456"
identifier: ecs-example
- type: AWS::ECS::Service
region: us-west-2
accountID: "34567345673"
identifier: ecs-example-2x-cortex-infra:
aws:
ecs:
- clusterArn: abcd
serviceArn: efgh
- clusterArn: stuv
serviceArn: wxyzaws.details().resources.filter((resource) => resource.typeName == "AWS::Lambda::Function").length > 0aws.details().resources.filter((resource) => resource.typeName == "AWS::Lambda::Function" and resource?.metadata?.get("Runtime")?.matchesIn("(python3\\.6|python2\\.7|dotnetcore2\\.1|ruby2\\.5|nodejs12\\.|nodejs10\\.|nodejs8\\.10|nodejs4\\.3|nodejs6\\.10|dotnetcore1\\.0|dotnetcore2\\.0|nodejs4\\.3-edge|nodejs$)")).length == 0 apm_api_catalog_read
dashboards_read
metrics_read
timeseries_query
apm_service_catalog_read
slos_read
apm_read
You can create this in Datadog under Organizational Settings > API Key.
Account alias: Enter a name that Cortex will associate this configuration with.
App key: Enter the application key you generated in Datadog.
This key appears under the Key column in Datadog while viewing your list of Application Keys.\
API key: Enter the API key you generated in Datadog.
Region: Select your from the dropdown.
Custom subdomain: Enter the custom subdomain for your Datadog instance.
This field only takes the subdomain, not the entire URL. For example, this field would take cortex-docs from https://cortex-docs.datadoghq.com.
Environments: Optionally, enter environment tags for Datadog entities.
If you set an environment tag here, make sure to set the to match.
Click Save.
You can use the datadog.metrics() expression to evaluate the health of your entities in a Scorecard:
This rule makes sure that a given entity's average CPU usage is less than 10% over the last two days.
Name
Overall state
Query
Tags
URL
Definition: datadog.monitors()
Example
For a Scorecard focused on operational maturity, this expression can be used to make sure an entity has at least one Datadog monitor set up:
Operation
Remaining budget
SLI value
Datum
Timeseries
SLO target
Source
Thresholds
Name
Threshold
Definition: slos()
Examples
For a Scorecard focused on operational maturity, this expression can be used to make sure an entity has associated SLOs in Datadog:
This rule checks that there is at least one SLO is set up. While this rule makes sense in a Scorecard's first level, a rule checking the status of the SLO would make sense in a higher level:
Entities will pass this rule if all SLOs associated with it have "passing" status.
tag
Tag for the project in Datadog
✓
value
Value for the project; Cortex will find monitors and SLOs by querying tag:value OR tag:value2 ...
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
id
Datadog ID for the monitor or SLO
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
If you’re using a self-hosted instance of SonarQube, you’ll need to verify that your Cortex instance is able to reach the SonarQube instance.
If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your SonarQube instance.
There are two options for integrating SonarQube: the default configuration method and Cortex Axon Relay, a relay broker allows you to securely connect your on-premises SonarQube data.
Configure SonarQube with the default method
Prerequisites
Before getting started, create a SonarQube user token:
Configuration
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select SonarQube.
Click Add configuration.
Configure the SonarQube integration form:
Account alias: Enter the alias you will use to tie entity registrations to different configuration accounts.
Token: Enter your user token from SonarQube.
SonarQube URL: Enter the URL for your SonarQube instance.
Click Save.
Configure SonarQube with Cortex Axon Relay
See for instructions. Make sure to follow the SonarQube-specific instructions for the docker-compose.yml file.
If you’re unable to expose your SonarQube instance to be reachable by Cortex, you can set up a custom integration webhook. To learn more about SonarQube webhooks, visit their webhook documentation.
By default, Cortex will use the Cortex tag (e.g. my-entity) as the "best guess" for SonarQube component key. For example, if your Cortex tag is my-entity, then the corresponding component key in SonarQube should also be my-entity.
If your SonarQube component key doesn't cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
If you’re using build-system tooling to push analysis to SonarQube, the plugin (e.g. Gradle, Maven) may be automatically generating a project key that’s different from the repo name.
Connect SonarQube entities via the Cortex UI
Navigate to an entity's details page in Cortex.
In the upper right corner, click Configure entity.
Click the Code quality link in the sidebar. \
In the center of the page, configure the details for your SonarQube project:
Alias: If you have multiple configurations, select the one that this project is associated with.
Project: Enter the project's name.
Click Save changes.
Editing the entity descriptor
When managing entities via the , you can configure SonarQube projects under the x-cortex-static-analysis block:
Cortex only supports one SonarQube project per entity.
Once the integration is established, data from SonarQube will be available in the Code & security page in an entity's sidebar, as well as under the Overview tab. You can pull in data on code smells, bugs, code coverage, vulnerabilities, and any custom metrics available through Sonar. You can read more about metric definitions in Sonar's documentation.
Metrics
Complexity
Duplications
Issues
Maintainability
Quality gates
Reliability
Security
Size
Tests
Code freshness
Code coverage
With the SonarQube integration, you can create Scorecard rules and write CQL queries based on SonarQube projects.
See more examples in the CQL Explorer in Cortex.
Yes. You can integrate with SonarCloud by following the same steps as integrating with SonarQube. In the URL field, use your https://sonarcloud.io/ URL. You can also use multi-account support to add a self-hosted or SonarCloud instance by adding the URL for that instance during configuration.
This means that Cortex is unable to talk to your SonarQube instance. Make sure that your instance is running and accessible to Cortex.
Gradle automatically generates a project key which is equal to [$:]$. As a result, automatic discovery won’t work. You’ll need to override the project key in your Cortex entity descriptor.
Try the following troubleshooting steps:
Make sure the project key in your YAML is exactly the same as the key in SonarQube.
Verify that the scores are in the “default branch” in SonarQube. If your scores are showing up in a branch-a in SonarQube, but your SonarQube default branch is main, Cortex will not be able to retrieve the scores.
Run the following curl command and verify there are metrics showing up in the response:
If you don't have control of or access to the integration touchpoint (for example, if you're using a SonarQube notification webhook) you'll want to use the API to send custom data. You can find information on sending data to a custom data webhook here.
Component key not found?For SonarQube (and all integrations), Cortex will map the Cortex tag defined in the cortex.yaml for a given entity. For SonarQube specifically, the tag must exactly match the project ID in SonarQube. If these are not one-to-one, we recommend using the override detailed above to define the proper mapping for project ID and entity name.
Sonarqube: Fail to request url on my integration page or a validity check failed error while creating a Workflow?This can happen if your external DNS certificate expired. Ensure that any certificates you're using are valid.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Depending on how you want to manage teams and the corresponding hierarchy, you can choose one of the following options:
Manage teams based on Workday supervisory organizations
Manage teams based on Workday teams
The required fields in the report differ depending on which option you choose. See the tabs below for instructions.
Your report will need the following fields:
email: Email address for employee. Use the same address that employees will use to access Cortex.
employeeId: Unique ID for each employee.
firstName: Employee first name. This will be displayed in Cortex.
lastName: Employee last name. This will be displayed in Cortex.
employeeRole (optional): Employee role. This will be displayed in Cortex.
employeeSupervisoryOrgId: The ID for the supervisory organization that the employee is in. Cortex uses this field to group employees.
teamDisplayName: A display name for individual teams based on the employeeSupervisoryOrgId; this should be the same across all employees who belong to the same supervisory org. This will become the Cortex team name and tag.
managerEmail: Email address for the employee's manager. If Cortex detects an employee with the same email as the managerEmail, that employee will be added to the team with a "Manager" role.
teamSupervisoryOrgId: The supervisory org ID for the team that the employee is part of. The organization registered in this field will become a "parent" in the team hierarchy, while the org registered in employeeSupervisoryOrgId will become a "child" in the hierarchy.
teamListKey (for One Employee - Multiple Teams): Key for the list of teams associated with a given user.
Any changes to the employeeSupervisoryOrgId will result in the creation of a new team because this field is how Cortex identifies teams.
Your report will need the following fields:
email: Email address for employee. Use the same address that employees will use to access Cortex.
employeeId: Unique ID for each employee.
firstName: Employee first name. This will be displayed in Cortex.
In Cortex, navigate to the Workday settings page:
Click Integrations from the main nav. Search for and select Workday.
Click Add configuration.
Configure the Workday integration form:
Username: Enter the username associated with the Workday account used to generate the ownership report.
Password: Enter the password for the Workday username.
Ownership report URL: Enter the URL for the ownership report you generated.
Provide the base report URL. Do not include query parameters in the URL. If necessary, Cortex will append ?format=json
Click Save.
After saving the configuration, you can configure how you want the fields to map to different elements in Cortex. The options available in each dropdown menu will mirror the fields included when generating the ownership report.
Configure the mappings:
Employee Attributes: Map report fields that pertain to employees, including the following:
Employee ID
First Name
Last Name
Role (optional)
Imports employees' roles and populates a badge that appears next to an employee's name.
Manager Email
When added, lists the corresponding manager for a given employee. The report should also include an entry for the manager to populate the field.
Team Attributes: Map report fields that pertain to employees' teams.
Team type: Select whether to map the fields using One Employee - One Team or One Employee - Multiple Teams.
The One Employee - One Team configuration is best if your report includes employees who belong to a single team. The
At the bottom of the screen, click Save.
If you choose to automatically import Workday teams, you must also configure the hierarchy fields mappings:
Field on parent team: The value selected becomes a parent team for value selected in Field on child team.
Is List: Toggle on when an entry for the parent field is a parent to multiple teams.
Field on child team: The value selected is defined as child team.
Root Team IDs: The ID for the team you expect to be at the top of the hierarchy.
If set, Cortex will use this to that may be in the hierarchy.
Note that you must enable the option to auto-import Workday teams in order to import hierarchies.
By default, Cortex will use the Cortex tag (e.g. my-entity) as the "best guess" for Workday team. For example, if your Cortex tag is my-entity, then the corresponding name in Workday should also be my-entity.
If your Workday teams don’t cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
Note: The team name is case-sensitive and should be exactly the same as in the report's teamDisplayName or teamName field.
You can choose to automatically import discovered teams and team relationships from Workday into Cortex. Before enabling auto import, make sure your Workday report includes the managerEmail field to ensure that team relationships are imported.
Navigate to Settings > Entities > Teams in Cortex.
Under Enabled identity providers, make sure the box is checked next to Workday.
Under Enable auto import of teams, click the toggle next to Auto import teams to turn this setting on.
The next automatic import will occur when the background entities sync runs at 9 a.m. UTC.
You can also manually trigger this sync:
Navigate to Catalogs > Teams in Cortex.
Click Create team.
In the upper left corner, click Sync teams.
type
Ownership type (in this case, group)
✓
name
The linked to the auto-created Workday team
✓
provider
The source of the team (in this case, it was a Cortex-created team)
✓
description
Description for the owner
Once the integration is set up, Cortex will automatically import and structure your team hierarchy. Any teams imported from Workday will appear with a description: "Automatically created by Cortex".
On each team's details page, any team members Cortex detects will populate under the Members tab. If you included the "Role" field in your Workday report, members' roles will appear in a badge next to their names.
Cortex syncs teams from the report every day at 9 a.m. UTC.
You can sync teams manually at any time by clicking the Sync teams for Workday button from Workday settings page in Cortex. Doing so will not auto-import teams.
Cortex does not support hierarchies with cycles. For example, let's say Employee A is on the platform team, Employee B is on the frontend team, and both report to Manager C on the engineering team. If Manager C reported to someone on the platform team, that would create a cycle between the platform and engineering teams.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
In the video below, see an overview of how Cortex helps you build a unified developer portal and catalog that improves visibility, adoption, and productivity:
You can create your own entity types or use one of the default entity types.
By default, Cortex supports the following entity types:
Services: The default type and the core of your catalog, used for entities such as microservices, libraries, components, etc – essentially any codebase-like module. Learn more in Add services.
Domains: An entity that allows you to group your services, resources, and other domains into hierarchical, logical units. Learn more in Add domains.
Teams: An entity to store all of your team data. Learn more in Add teams.
Cortex also supports pulling in resources directly from AWS, Azure Resources, and Google Cloud as their corresponding types.
For AWS, you can select which entity types to include in your .
For Azure Resources, you can select which entity types to include in your .
For Google, see the list of .
In addition, you can create custom entity types to fit your organization's needs. Learn more in Add custom entity types.
Before changing an entity's type, you must enable the setting to allow changing an entity's type. The type can only be changed via the entity's YAML.
Whether you use the UI or GitOps to manage entities, every entity in your Cortex catalogs is defined by a YAML file called the Cortex entity descriptor, also referred to as an entity's Cortex YAML (stemming from cortex.yaml, the name of the file that powers the GitOps approach.)
Learn more in Defining entities via YAML file.
Any additional metadata you add to your descriptor belongs in the info section of the YAML file. Throughout the Cortex docs, you'll see snippets that start with x-cortex-* – make sure to add this to the info section.
Learn about the available x-cortex-* blocks in Defining entities via YAML file.
By default, your account is configured to edit entities through the UI. We recommend starting with the UI editor, which includes a built-in YAML editor, then switching over to GitOps when ready for a wider rollout.
If you want to use GitOps to manage your entity YAML files, you can change this setting:
In Cortex, navigate to Settings > GitOps.
Scroll down to the "Options by entity type" tile.
To only allow editing of entities via GitOps, toggle off the setting next to Enable UI editing for new entity types.
To only allow creation of entities via GitOps, toggle off the setting next to Enable UI importing for new entities.
If you want to adjust these settings per entity type, you can disable the toggles for individual entity types. In the list of entity types, disable the toggles next to UI editing and UI importing to use a GitOps approach instead of the UI. \
When using GitOps, you can define any number of entities in any repository.
Domain definitions should live in the .cortex/domains directory in your repository.
Team definitions should live in the .cortex/teams directory in your repository.
You may store all of your entity definitions in a single repository or you can store the YAML in the repository of the corresponding service.
See the single repository example below:
Read more in Using GitOps for Cortex.
The Cortex tag (formerly known as the entity tag) - the value of x-cortex-tag in an entity's YAML file - is a customizable unique identifier that's used throughout Cortex. For example, the Cortex tag is used to declare dependencies on other entities or look up information using the Cortex Slack Bot.
The Cortex tag must be globally unique across all entities.
If you attempt to edit an entity’s x-cortex-tag, Cortex will create a new entity with the updated tag while keeping the original entity unchanged. This happens whether you make the change in the UI editor, through the API, or via GitOps. This means both entities will exist until you manually archive or delete the old one.
If you want to re-use an x-cortex-tag value that was previously associated with an entity, the original entity must be deleted before that tag can be used on a new entity.
A Cortex ID (CID) is a unique, immutable entity ID that can be used outside of Cortex for historical tracking and reporting. It can be used in the API, in CQL queries, in-app, and you can use it with the Cortex Slack Bot. The ID is automatically generated by Cortex and it is 18 characters in length.
In Cortex, the CID for an entity appears in the URL for an entity and at the top of an entity page:
The CID does not appear in an entity's YAML file, as it cannot be modified.
After an entity is imported or created, it will automatically belong to a catalog based on the entity type criteria set for each catalog. When you create a custom catalog, you can set the entity type criteria.
For the default catalogs, the entity type criteria is set by default:
The Services catalog contains service entity types
The Domains catalog contains domain entity types
The Teams catalog contains team entity types
The Infrastructure catalog contains any entities that are not the types service, domain, or team.
Its catalog filter is set to exclude the types service, domain, and team:
The All entities page lists all entities that have been imported into Cortex, across all types. This page will open to the Mine tab when a user owns any entities; otherwise, it will default to the All entities tab.
Once you’ve imported entities, you’ll be able to see the entity’s name and tag. In the beginning, you may have just a few dozen entities, but eventually you may have hundreds, if not thousands, of entities across all catalogs.
There are several ways to search and filter your entities list:
To find specific entities, use the search bar in the upper right corner of the entities list and type to search.
Click Name to select whether you want to sort by name or identifier, and whether to sort ascending or descending.
Click Display to choose whether to show archived entities in the list, and select which columns to display alongside entities. Learn more about the performance indicator columns below.
Click Filter to narrow down your list by associated Git repository, unowned entities, AWS account ID or region, domain, entity type, group, team, or user.
Click Display to select whether to display the following key performance indicators as columns alongside entities:
Incidents: Displays how many active incidents are associated with a given entity. This information is pulled from FireHydrant, incident.io, PagerDuty, and Rootly.
Health: When you click into this column in an entity's row, you can view more information on:
Monitors: Shows how entities are performing against monitors you’ve created in your APM. When an entity is passing all monitors, this cell will display All OK; otherwise, it will display Failing, Warning, or No Data, along with how many monitors the entity is not hitting. This information is pulled from Datadog.
Error rate: Shows the percentage of transactions that result in a failure during a pre-specified window. This information is pulled from New Relic.
Apdex (Application Performance Index): Ratio of the number of satisfied and tolerating requests to the total number requests made. This information is pulled from New Relic.
If you have not set up an integration needed to populate a column, that column will display "Not connected." If an integration is established, but the data and/or configuration for an entity do not exist, the cell will display “None.”
To view all entity types, go to Catalogs > All Entities then click the Entity types tab.
A Cortex logo appears next to built-in entity types. When you hover over the logo, you will see a "Powered by Cortex" banner:
The other entity types in the list are custom types. To learn more about creating entity types, see Add custom entity types.
Relationship types allow you to define, manage, and visualize relationships between entities within your Cortex workspace.
To view all relationship types, go to Catalogs > All entities then click the Relationship types tab.
To learn more, see Defining relationship types.
It's possible to delete entities, but for historical posterity you may want to archive entities. To keep your data up to date without manual effort, we recommend configuring auto-archival of entities when they are no longer detected in your integrations or when their corresponding YAML files are deleted.
It is also possible to manually archive entities in the Cortex UI or via the API. Learn more in Archiving entities.
To learn more about adding each type of entity, see their documentation pages:
Admins, or users with the Configure settings permission, can adjust system-wide settings for entities under Settings > Entities > General. Learn more in Entity settings.
Required if method is present
description
A description of the dependency.
Yes
metadata
JSON metadata tags for the relationship. Supports arbitrary objects.
Yes
Every entity you add to your workspace is associated with an entity type. Cortex comes with several built-in entity types, but you can create unlimited custom entity types to extend your catalogs.
There are two distinct parts of this process: Creating the entity type itself (via the UI or API), then creating entities of that custom type (via the UI, GitOps, or API).
Want to learn more? Check out the Cortex Academy course on Catalogs, Entities, and Relationships, available to all Cortex customers and POVs.
To view all entity types, go to Catalogs > All Entities then click the .
A Cortex logo appears next to built-in entity types. When you hover over the logo, you will see a "Powered by Cortex" banner:
The other entity types in the list are custom types.
You can create custom entity types:
Manually in the Cortex UI
Via the
When creating an entity type, keep in mind that these will ultimately dictate how you import specific entities later on. After creating the type itself, you will be able to (via the UI, API, or GitOps).
To create, edit, and delete entity types, your user or API key must have the Edit entity types permission.
Create entity types in the Cortex UI
In Cortex, navigate to Catalogs > All entities.
Click the Entity types tab, then click Create entity type.\
Configure the form:
Entity type definitions require a JSON schema that outlines the attributes that entities should conform to.
Custom entity type definitions are powered by the open-source project.
The JSON schema for a custom entity type ensures consistency and validation when creating entities of that type. The attributes listed under required in the schema must be defined for entities of that type according to the outlined properties.
In the example below, location is required when creating this type of entity, but the schema also includes department as a possible property.
When creating a new entity of the custom type, if the entity type's JSON schema requires certain attributes, you must include the metadata for those attributes on that entity.
Defining a JSON schema enables visibility on an . The schema and the defined properties will appear under the Metadata section on the entity's overview, making it easy for you to identify key specs.
In the example below, the entity "Sally S" displays metadata for the property "location."
After , you can create entities of that custom type:
in the Cortex UI
in the via
via the
To create custom entities, your user or API key must have the Edit entities permission.
Create custom entities in the Cortex UI
Before creating a custom entity in the UI, make sure you have UI-based editing enabled for this entity type in .
In the main nav of Cortex, click Catalogs > All entities.
At the top of the Services page, click +Import entities.
Choose Create entities manually.
It is possible to edit entities after creating them:
Navigate to the entity's page.
In the upper right corner, click Configure entity.
Make any desired changes.
Note: The only field you cannot edit is the identifier.
After an entity is imported or created, it will automatically belong to a catalog based on the entity type criteria set for each catalog. When you , you can set the entity type criteria.
By default, any you create will belong to the Infrastructure catalog. If you do not want the entity type to belong to this catalog, you can add the entity type to a different catalog's definition.
After creating a custom entity type, you can view or edit its schema, view a list of entities of that type, and validate the schema of entities of that type.
You can view a custom entity type's schema and a list of entities of that type.
Navigate to Catalogs > All entities, then click the .
Click into an entity type.
The schema is displayed on the entity type page.
Navigate to Catalogs > All entities, then click the .
Click into an entity type.
In the upper right corner, click Edit.
Make changes to your entity type, then at the bottom of the page, click Save.
Navigate to Catalogs > All entities, then click the .
Click into an entity type.
Click the Schema linter tab.
In the text editor, paste in your entity's JSON schema to verify that it is properly formatted for this entity type.
In some instances, you may want to use custom data instead of a custom entity type. This is recommended if you need more flexibility for these entity types; they may not always require specific metadata.
While a custom entity type's metadata will appear on the overview of an , custom data does not appear there. Instead, it appears in the Custom data sidebar of an entity details page.
It is possible to create an entity type with an empty properties schema:
This entity type will display in the catalogs, but entities of this type won't be validated against certain specs. Such properties can instead be defined using .
A schema is ideal for enforcing static properties across all entities, while custom data allows users to augment and update attributes.
Ownership is a core use case of Cortex, as many organizations seek to establish accurate ownership of services, data, and other entities. Accurate ownership is foundational for accountability, incident response, security reviews, compliance, and developer productivity. Without clear ownership, critical issues can go unresolved and services can fall through the cracks.
Avoid inefficient manual processes: Use to solve entity ownership quickly. Cortex automatically predicts entity owners so your developers don't waste time hunting down the wrong person.
Ownership can be defined by accepting Cortex's automated recommendations for ownership, pulled in from third-party integrations, or defined manually in the Cortex UI. Ownership can also be inherited from an entity's .
Ownership drives which users will receive from Cortex, including alerts for on-call changes, when is needed on an assigned entity, when an entity is re-evaluated and its Scorecard changes, and more.
is a container orchestration system that automates software deployment, scaling, and management. The Cortex K8s agent is a lightweight agent that collects information from your cluster (Deployments, StatefulSets, Argo Rollouts, and CronJobs) and surfaces it in your Cortex workspace's catalog, Scorecards, and more.
Integrating Kubernetes with Cortex allows you to:
directly from K8s clusters into Cortex, making it easy to keep the catalog in sync with what's actually running in production
in Cortex, giving you visibility into your infrastructure and how services are deployed
is a performance tracking and analytics tool that helps engineers gain visibility into their software. Integrating New Relic with Cortex allows you to:
Discover entities and track ownership
View SLO and monitoring information on entity pages in Cortex
Embed New Relic dashboards on entity pages in Cortex
Teams serve as both an entity representing your organization in Cortex and as for different entities in the catalogs. Teams offers a centralized place for the most important information about each group, making it easier for everyone to find what they need.
Teams can be assessed via , interact with integrations, and leverage . They can also be configured in a hierarchy.
To view your teams, navigate to Catalogs > Teams.
When you open the , you'll see
Use Scorecards to establish best practices, track migration, promote accountability among teams, enforce standardization across entities, or define maturity standards.
This page explains how to create a Scorecard from the Cortex UI. For instructions on creating Scorecards via GitOps, see . You can also work with Scorecards via the .
Learn about reviewing, evaluating, and taking action on failed rules in .
For information about common use cases and examples, see .
Reviewing a Scorecard's evaluation gives you insight into patterns across teams or entities, and areas to prioritize for improvement.
When an entity is failing a rule in a Scorecard, Cortex provides the information needed to review and remediate the issue efficiently. From there, teams can . Resolving these failures not only improves the health and maturity of individual entities but also strengthens the overall reliability and compliance posture of the engineering organization.
After you create and save a Scorecard, Cortex automatically evaluates the entities that the Scorecard applies to. How often the Scorecard is evaluated depends on the evaluation window you set when .
x-cortex-apm:
datadog:
serviceTags:
- tag: entity
value: brain
alias: my-default-alias
- tag: entity
value: cerebrum
alias: my-other-aliasinfo:
x-cortex-apm:
datadog:
monitors:
- id: 12345
alias: my-default-alias
- id: 67890
alias: my-other-aliasinfo:
x-cortex-slos:
datadog:
- id: 0b73859a3e2504bf09ad23a161702654
alias: my-default-alias
- id: 228499184a9efe34d4e4e9df838c7fa1
alias: my-other-aliasx-cortex-apm:
datadog:
serviceName: cortex-gateway.gatewaydatadog.metrics(query="system.cpu.usage{service:" + datadog.serviceNames().join(" OR service:") + "}",lookback=duration("P2D")).averageBy((point) => point.metricValue) < 0.10datadog.monitors().length >= 1slos().length > 0slos().all((slo) => slo.passing)sonarqube.freshness() <= duration("P7D")sonarqube != nullsonarqube.issues(types = ["bug"], rules = ["java:S2142"], severities = ["major"]).length <= 3 curl -v -u : "https://[SONARQUBE HOST]/api/measures/
component_tree?component=[SONARQUBE PROJECT KEY]&metricKeys=ncloc,coverage"ownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)ownership.teams().all(team => team.description != null and team.isArchived == false)x-cortex-owners:
- type: group
name: workday-team-tag
provider: CORTEX
description: This is a description for this owner..
└── .cortex
├── catalog
│ ├── database.yml
│ ├── s3-bucket.yml
│ ├── auth-service.yml
│ └── billing-service.yml
├── domains
│ ├── billing-domain.yml
│ └── health-domain.yml
├── teams
│ ├── eng-team.yml
│ └── sre-team.yml






lastName: Employee last name. This will be displayed in Cortex.
employeeRole (optional): Employee role. This will be displayed in Cortex.
teamName: Team name for employee. This field is what we use to group employees into teams in Cortex.
teamDisplayName (optional): Display name for the team. This will be used for the title and the tag for any teams imported from Workday at time of import. If not included, teamName will be used instead. This should be the same for all employees on the same team.
managerEmail: Email address for the employee's manager. Cortex uses this field to create team hierarchies. If Cortex detects an employee with the same email as the managerEmail, that employee will be added to the team with a "Manager" role.
Omit this field if you do not want to auto-import teams and the corresponding hierarchy from Workday.
Any changes to the teamName will result in the creation of a new team because this field is how Cortex identifies teams.
One Employee - Multiple TeamsIf using One Employee - One Team:
Team ID: Enter the team ID. New teams are imported based on this ID. If the identifier (i.e. teamName) changes, Cortex will create a new team.
Team Name: Enter a display name for the team in Cortex. Cortex will update this name if changes are detected in Workday.
If using One Employee - Multiple Teams:
Team List Key: Enter the list key for the list that contains teams you want imported into Cortex for a given employee entry. This requires the teamListKey field in the Workday report. The teamListKey should be a list of objects, where each object has at least teamName and teamId properties:
Team ID: Enter the team ID. New teams are imported based on this ID. If the identifier (i.e. teamName) changes, Cortex will create a new team.
Team ID - Fallback: Enter a fallback team for a user who does not have an associated teamListKey.
Team Name: Enter a display name for the team in Cortex. Cortex will update this name if changes are detected in Workday.
Team Name - Fallback: Enter a fallback team name for the fallback team ID defined above.
For example, https://sonarcloud.io if you are on SonarQube Cloud, or https://sonarqube.mycompany.com if your organization has their own instance.
project
Project key defined in Sonarqube
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)


x-cortex-static-analysis:
sonarqube:
project: sonar-project-key
alias: sonarqube-aliassonarqube.metric("coverage") > 0.80sonarqube.metric("vulnerabilities") <= 2sonarqube.metric("vulnerabilities") = 0sonarqube.metric("coverage") > 80sonarqube.metric("security_hotspots") < 2sonarqube.issues(types = ["code_smell"], severities = ["minor"]).length < 5sonarqube.issues(types = ["code_smell"]).length < 1Name: Enter a human-readable name that will appear in the catalog for this entity type.
Type: Enter a unique identifier that corresponds to the entity type. This will be used to specify the type defined in the YAML definitions for imported entities.
Description: Optionally, enter a description for the entity type.
Display icon: Select an icon to appear alongside the entity type throughout the app.
Schema: Define a JSON schema that will be used to validate the x-cortex-validation block of a given entity’s YAML.
This can be used to enforce certain attributes about entities, such as a region or version number. Attributes defined in the schema will be required when creating an entity of that type, which can then be validated in Scorecards. Learn more under JSON schema for custom entity types.
In the example screen shot below, we’ve created a custom entity type called Employee — this is what we’ll use to represent individuals at our organization. In the schema section, you can see that each profile is required to include an employee’s location. This means every time you create an entity of type "Employee," you will define the employee's location.\
At the bottom of the page, click Create.
After saving, the entity type will appear in the Entity types tab under Catalogs > All entities, and you are now able to import entities of that type.
If you want entities of the new entity type to automatically belong to a specific catalog, you can configure the catalog's defined entity types while creating a new catalog or you can edit an existing catalog to update the entity types.
Create entity types via the API
You can create, update, and delete entity types using the .
Learn more about the JSON schema below.
Configure the form:
Type: Select your custom entity type.
Entity schema: Enter a JSON schema to define your custom entity.
For example, if the entity type's schema requires location and department, your new entity's schema might look like this:\
Click Show example above the schema to view an example of how the entity's schema should be formatted. To use the example as a starting point, click Copy example then paste it into the Entity schema text editor.
See for more information.
Entity name: Enter a human readable name for your entity.
Identifier: This field is auto-populated based on your entity name. It is a unique identifier for your entity. This is also known as the x-cortex-tag.
Description: Enter a description of the entity to help others understand its purpose.
Groups: Select your entity.
Owners: Define for your entity. We recommend selecting team owners to keep your ownership information up-to-date through any future personnel changes.
Links: Add links to external documentation, such as runbooks, docs, logs, or custom categories.
Parents: Define parent domains. This is where you configure the hierarchy for your entity. These can be visualized in the .
Dependencies: Select entities that this entity depends on. These can be visualized in the .
On-call: Configure on-call information.
Repository: Select the repository associated with this entity.
When you are finished, click Confirm import at the bottom of the page.
Create custom entities in the entity descriptor
Before creating a custom entity via GitOps, make sure you have UI-based editing disabled for this this entity type in Settings > GitOps.
If your entity is of a custom type, you must specify x-cortex-type and x-cortex-definition.
The x-cortex-definition field is validated against the entity type definition that you created via the UI or API. If your custom entity type does not have specific requirements, entities of that type still need a non-null definition specified, like x-cortex-definition: {}.
Example cortex.yaml
You can create, read, update, and delete entities via the .
To delete entities, your API key must have the Delete entities permission.
At the bottom of the screen, click Save changes.
Learn more about the health and incident data columns in Key performance indicators listed for all entities.\
You cannot edit the entity type's unique identifier.
On the right side of the page, click Show example to see an example of how the schema should be formatted.
If you want to use the example as a starting point, click Copy example, then paste it into the text editor.
In the upper right side of the text editor, click Validate Schema.
type
Type of entity and/or required component: array, boolean, integer, null, number, object, or string
Yes
required
Required specs for the entity type
properties
Properties of the required specs (including type)
Yes only if the required field is not null






When viewing an entity, the owners appear in the metadata bar on the right side of the page:
Click into the team name to view the team's entity page, including a list of members and a list of entities owned by that team.
You can create or import the teams and users who will be defined as owners for your entities.
There are a few ways to determine which of your entities in Cortex don't have owners assigned yet:
Use the Ownership tool to see unowned entities and Cortex's automated recommendations for owners
Learn more about using the Ownership tool below.
View the Executive Report, which lists unowned entities
Launch an Ownership Verification Scorecard, which will automatically add tasks to your Engineering homepage to ensure you add owners to entities
When , select the Ownership Verification template.
You can define owners based on:
A team: The user is a member of a team that is listed as the owner of an entity.
We recommend setting up teams as owners. If you link a group in your YAML file from a different platform (such as Okta), the members of the team will be automatically updated in Cortex if anyone leaves your organization and is removed from your integrated identity provider.
A user email address: The user is listed as the owner of an entity.
configured in an entity's hierarchy.
Owners can be defined:
By accepting Cortex's automated recommendations for owners, based on repository activity
By pulling information from third-party integrations in the entity descriptor YAML
Ownership can also be inherited via fallback or append configuration.
Directly in the Cortex UI
Automatically if Cortex detects that an entity is owned by a team that does not yet exist in Cortex
If an entity's YAML references a team, but that team doesn't have a corresponding entry within Cortex, Cortex will automatically create a team. The team will include a label that says Automatically created by Cortex.
Cortex automated recommendations for ownership
Cortex analyzes a repository and automatically recommends a team owner for entities that do not have an owner.
If an entity does not have an owner and Cortex has recommendations for who the owner should be, it will be flagged in the ownership tool under Tools > Ownership, in the "Owners" section of an entity details page overview, in the "Owners" sidebar link on an entity details page, and it will appear during the import process when .
Review ownership recommendations in bulk
Users can edit ownership on this page only if they have edit access for all entities. If a user only has edit access for some entities, they can accept ownership recommendations from an entity's details page,
To review and assign ownership across all unowned entities:
In the main nav of Cortex, click Tools > Ownership.
A list of recommendations for ownership is displayed.\
Review and accept the recommended owners.
Review ownership recommendations per entity
Users can accept ownership recommendations for an entity if they have edit access for that specific entity, and if UI editing is enabled for that entity type under .
On an next to the "Owners" field, click Recommendations.
Review the suggested owners. To accept a recommendation, check the box next to the recommended owner then click Add owners.
Define owners in the entity descriptor
The x-cortex-owners field allows you to define a list of owners of type email or group.
Cortex recognizes groups from the following integrations:
Define owners in the Cortex UI
In Cortex, navigate to .
Search for and select the entity whose ownership you want to edit.
In the upper right corner of the entity's page, click Configure entity.
Instead of defining ownership individually for every entity in your catalog, you can define ownership at the parent entity level and have that pass down to all of the entity's children. You can configure this in the Cortex UI while creating a domain entity and adding owners to it, or while creating an entity relationship.
inheritance can also be defined in the entity descriptor under the x-cortex-owners block, as shown in the example below:
The inheritance type for each owner can be one of APPEND, FALLBACK, or NONE. If not set, inheritance is defaulted to NONE.
APPEND: This owner is appended to the list of owners for all child entities.
FALLBACK: In the case where a child has no valid owners, including fallbacks, this fallback will be assigned as the owner. Note that this only applies to a child entity down the hierarchy; it is not the fallback for the parent domain itself.
NONE: This owner owns the domain, but not necessarily any of its children (no inheritance).
Cortex can automatically discover ownership for your AWS resources using their owner tag. To enable this, make sure that your AWS resources have an owner tag matching the x-cortex-tag of the corresponding Cortex team and enable the Sync ownership from AWS toggle in Settings > AWS.
You can pull in all resources from AWS, and Cortex syncs those owners automatically based on their tags in AWS, allowing you to easily keep the resource owners up to date.
To remove incorrect ownership in Cortex, the steps depend on how the ownership was added and your current configuration. Expand the tile below to learn more.
Under Settings > Entities, there are several settings relating to teams. Read more about these in the Teams documentation.
Create Scorecards to track progress and drive alignment on projects relating to Kubernetes, and to enforce Kubernetes best practices
Before getting started:
Reach out to the Cortex customer engineering team for the Helm chart used for deployment and a username and password.
Generate an API key in Cortex.
The API key should have the User (edit catalog entities) role at a minimum.
Note: It is also possible to programmatically create your API key via the .
The Cortex k8s agent uses a push model that ensures you do not need to expose your cluster to the public internet.
Additionally, the Helm chart comes with a predefined ClusterRole that provides the correct RBACs:
Permissions: ["get", "watch", "list"]
Resources: ["deployments", "services", "pods", "replicationcontrollers", "statefulsets", "rollouts", "cronjobs"]
API groups: ["apps", "argoproj.io", "batch"]
Communication out of the cluster to Cortex happens over HTTPS. There is no inbound traffic to the agent.
To connect Cortex to your Kubernetes instance, you’ll need to install the Cortex k8s agent in your Kubernetes cluster. The agent is lightweight and adds negligible impact to your cluster.
Create a Docker image pull secret:
Run the following command, replacing cortex-key with the value of your Cortex API key, to create a secret in your cluster:
Run the following command to install the Helm chart provided by Cortex:
By default, Cortex will use the Cortex tag (e.g. my-entity) as the "best guess" for Kubernetes resource. For example, if your Cortex tag is my-entity, then the corresponding resource in Kubernetes should also be my-entity.
If your Kubernetes resource don’t cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
See the table below for the methods of mapping resources to entities:
Services that own their K8s infra
By default, Cortex maps Kubernetes deployments with a cortex.io/tag annotation to Cortex entities with the same tag.
Annotation mapping should be at the default absolute path of .metadata.annotations."cortex.io/tag".
Shared infra or external-managed services
Specify a list of label keys in the Kubernetes integration settings page of your Cortex workspace
Complex or legacy workloads
Add the resource manually to your entity descriptor
See the tabs below to learn how to use each option:
Annotation
You can link your Kubernetes deployment to a Cortex entity by adding an annotation to your k8s deployment metadata. By default, Cortex maps Kubernetes deployments with a cortex.io/tag annotation to Cortex entities with the same tag.
Use cortex.io/tag as the key and use the value of x-cortex-tag in the Cortex entity's cortex.yaml as the value.
For example, if the cortex.yaml file is:
Then the deployment.yaml file should be configured as:
Customize annotation mapping
It is possible to customize annotation mapping in Cortex:
Label-based auto-mapping
You can override discovery and have Cortex discover Kubernetes resources using their metadata labels instead:
Editing the entity descriptor
Cortex accepts several k8s resources, which can be on different clusters or of different types: deployments, ArgoCD rollout, StatefulSet, and CronJob.
All of these resource types have the same field definitions:
See the Create services documentation for instructions on manually importing entities.
Kubernetes deployment data will be available in the Kubernetes block on the entity details pages for entities imported from Kubernetes or linked to a k8s resource.
In the entity's sidebar, click Environments to see Kubernetes deployments, clusters, active replicas, and pending deployments, as well as:
Replicas: Number of available, ready, and desired replicas.
Containers: Resource containers, including requested memory, memory limit, and CPU data. Also includes the full container definition.
Track and analyze your software delivery performance using real-time data from your Kubernetes environments in Eng Intelligence features.
Deployment data from your clusters is surfaced in Metrics Explorer and in dashboards, such as the DORA Dashboard, and can be used to assess key engineering metrics like deployment frequency, change failure rate, and more.
With the Kubernetes integration, you can create Scorecard rules and write CQL queries based on Kubernetes resources. For an example, see Cortex's prebuilt template.
See more rule examples in the CQL Explorer in Cortex.
The Cortex k8s agent is a cron job that runs every 5 minutes by default.
Make sure that the types you expected to see are in the cluster you are attempting to import.
If you're using Cortex's k8s agent to import entities into Cortex but don't see all expected namespaces during the import process, make sure app.namespace is commented out in values.yaml:
If app.namespace is defined the Cortex k8s agent will only be able to discover services from that namespace. This behavior can be confirmed with a backend log similar to:
Once app.namespace is commented out, restart your pods. You will then be able to see all expected namespaces when importing new services.
If your Cortex agent in Kubernetes clusters is blocked due to deprecation of Docker registry after an upgrade, you can make these direct edits using the same credentials:
Access the image from ghcr.io instead of docker.pkg.github.com.
Update the registry secret, setting the server to https://ghcr.io.
If you are unable to make these changes, please reach out to [email protected] and request a new Helm chart with this change already reflected.
When running the self-hosted Kubernetes agent successfully, users may see failing ArgoCD rollouts errors while not using this tool.
Cortex logs this exception for verbosity - this error is harmless if not using ArgoCD tool.
Yes - the Cortex Helm chart deploys two Cortex-specific pods from images for the frontend and backend, as well as a data store. You can use these images to run Docker containers on other platforms, such as ECS.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Create Scorecards to drive alignment on projects involving New Relic metrics
Before getting started:
As a full platform user in New Relic, create a New Relic user key.
New Relic user keys are linked to the account they were created from, so if this account is ever deleted, the integration with Cortex will stop working.
In Cortex, navigate to the New Relic settings page:
Click Integrations from the main nav. Search for and select New Relic.
Click Add configuration.
Configure the New Relic integration form:
Account alias: Enter a name for this account.
Personal key: Enter the user key you generated in New Relic.
Account ID: Enter the that the user key was generated with.
Use EU region: Optionally enable this toggle to use the EU region of New Relic.
Click Save.
Once you save your configuration, you'll see it listed on the integration's settings page in Cortex. If you’ve set everything up correctly, you’ll see the option to Remove Integration in Settings.
You can also use the Test all configurations button to confirm that the configuration was successful. If your configuration is valid, you’ll see a banner that says “Configuration is valid. If you see issues, please see documentation or reach out to Cortex support.”
After setting up the integration, you will be redirected to the New Relic settings page where you can enable the cross-account access feature. If you have an account that supports subordinate accounts, you can enable this setting to fetch applications and SLOs for all the accounts that are under the configured one.
The New Relic integration has multi-account support. You can add a configuration for each additional by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the New Relic page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
There are two ways to auto-map New Relic applications and services to Cortex entities:
By default, Cortex will use the Cortex tag (e.g. my-entity) or its name as the "best guess" for New Relic applications. For example, if your Cortex tag is my-entity, then the corresponding application in New Relic should also be my-entity. The name is not case-sensitive.
If your New Relic applications don’t cleanly match the Cortex tag or name, you can override this in the Cortex entity descriptor.
Cortex also supports mapping New Relic applications to Cortex entities via New Relic tagKeys. By default, a Cortex entity will be mapped to a New Relic application or service with New Relic tag key = "service" and tag value = the service's Cortex tag.
You can customize the tag key names on the in Cortex.
Note: Cortex does not support auto-mapping of SLOs. SLOs have to be defined via the entity YAML or attached to a mapped application or service.
Dependencies
Cortex automatically maps dependencies between your entities by utilizing New Relic's Service Map data.
Say you have two applications in NewRelic (Application A and Application B), and in the service map Application A calls Application B. In Cortex you have two Entities (Cortex Entity A and Cortex Entity B), where Cortex Entity A is mapped to New Relic Application A and Cortex Entity B is mapped to New Relic Application B. Cortex will take the mapped relationship from Application A to Application B and create a dependency from Cortex Entity A to Cortex Entity B.
See the Create services documentation for instructions on importing entities.
APM services
New Relic application metrics can be fetched for each entity using application IDs or tags.
applications
Specifies that the APM service should be found by application ID
✓
applicationID
ID for the application that the service belongs to
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
tags
Specifies that the APM service should be found by tag
✓
tag
Tag key for the APM service(s)
✓
value
Tag value for the APM service(s)
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
Instructions to find your Application ID can be found in the New Relic docs. You can also find the Application ID in the URL in New Relic.
You can also find information on finding and managing tags in the New Relic docs.
OpenTelemetry
OpenTelemetry services can be associated with the entity only using tags. For this type of service New Relic doesn't generate application ID.
tags
Specifies that the OpenTelemetry service should be found by tag
✓
tag
Tag key for the APM service(s)
✓
value
Tag value for the APM service(s)
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
Cortex fetches OpenTelemetry data every 5 minutes, but the data refresh may take longer depending on how much data you have.
Embeds
Cortex can also embed dashboards from New Relic.
type
Specifies the source of the embed; in this case, should be newrelic
✓
url
URL for the dashboard. It must be publicly accessible, or if you can access the iFrame via VPN, it should be accessible in Cortex while also on the VPN.
✓
Learn more about embedding charts in the Adding external docs page.
SLOs
SLO can be fetched for each entity using New Relic entity GUID for respective SLO or associated service. Detailed instructions how to obtain entity GUID can be found in New Relic docs.
Fetched SLO information can be found in the Operations and Integrations sections of an entity page.
id
New Relic entity guid for the SLO or the associated service; if you use the GUID for a parent service, all SLOs associated with it will be imported into Cortex
true
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
If the alias is not specified, like with the third ID above, Cortex will use the default configuration.
If you use the GUID for a parent service to define the SLOs for a given entity, Cortex will import all SLOs associated with that service.
When entities are tied to New Relic, SLO and monitoring information appear under the Monitoring section on the overview of the entity details page.
More data is available under the Monitoring page in the entity's sidebar:
Throughput
Response time
Error rate
Apdex target
Apdex score
Host count
Instance count
Concurrent instance count
In the SLOs section, you'll be able to see a list of all SLOs tied to that entity, the target and current SLO score, and the period of time the SLO is being calculated for. For example, if the time listed is "7 days ago," then the SLO is looking at the time range starting 7 days ago to now..
The SLO name will display in green when passing and orange when failing.
If you've defined dashboards in an entity's YAML, you'll be able to view the graphs from an entity's details page. Open the Dashboard page in the entity's sidebar. All dashboards defined in the descriptor will be embedded on this page.
New Relic dashboards must be defined individually for each entity.
Dependencies detected from New Relic will appear in Relationship graphs. You can manually sync dependencies in the Relationship Graph.
With the New Relic integration, you can create Scorecard rules and write CQL queries based on New Relic performance metrics.
See more examples in the CQL Explorer in Cortex.
OpenTelemetry metrics
OpenTelemetry metrics available in the New Relic Metrics Exlorer can be accessed or manipulated for a given entity by combining CQL and NRQL native query.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
On the right side of the Teams catalog page, see the Scorecard Leaderboard, which highlights the ten best-performing teams within your organization.
The leaderboard is calculated from the average of Scorecard scores for all entities owned by a team. Change in rank is based on the team's score 7 days ago. You can use the dropdown to select a different Scorecard, allowing you to view the leaderboard based on specific Scorecards.
The leaderboard gamifies entity quality and encourages team members to achieve goals. This creates a culture of accountability, where everyone has visibility into how they're performing.
Each team has its own details page, where you can view key details about the team. Click a team from the Teams catalog page to view its details.
At the top of a team details page, you’ll find on-call information, Slack channels, and parent and children teams.
Additional information appears in tabs on the team's details page:
The Overview tab includes:
Vulnerabilities and issues from linked integrations.
How the team is performing across Scorecards. By default, this will show the level that the team’s entities have reached in each Scorecard.
On the right, enable the toggle next to Aggregate children scores to include child entities in the Scorecard overview.
A list of recent events associated with this team, such as alerts from .
The Dependencies tab shows any incoming or outgoing dependencies associated with this team.
The Team members tab includes a list of all team members and their roles. When available, Cortex will also pull in profile photos from your Git provider.
The Entities tab shows a list of all entities that the team owns.
Learn more about the sidebar links in the Entity details page documentation.
Teams not only allow you to collect vital information in a single place, but are also crucial for ownership. Rather than assign an entity to individual team members, you can assign ownership to an entire team. This makes it easy to assign multiple team members to an entity, and it ensures that when a team’s composition changes, ownership is updated accordingly.
Read more in the Ownership documentation.
You can create teams:
By importing them from a connected integration (e.g., Workday, GitHub)
Manually in the Cortex UI
Via the entity descriptor YAML through GitOps
Via the
You can configure teams to reflect the actual hierarchy at your organization while creating or importing teams in Cortex. A team can be defined as the parent of one or more teams while also being the child of another team.
When you access the Teams catalog, individual teams and parent teams are displayed by default. Parent teams have an arrow next to their name, indicating that you can expand to view children teams.
In the above example, My Company is a parent team with 7 child teams nested under it.
See the tabs below for instructions on each method.
Importing a team from an integration
If you have an existing source of truth for your teams and team members, we recommend importing teams. By integrating with your identity provider at this stage, Cortex will automatically sync team pages with your source of truth so you don't have to update information in more than one place when people join or leave teams.
Each integration syncs teams daily.
You can only import entities from integrations that have already been configured.
Supported integrations
Teams from the following integrations can be imported:
Before following the import process, you must .
For the Workday integration, you can enable .
Importing teams
After configuring an integration that includes teams, follow these steps to import teams:
In Cortex, navigate to Catalogs > All entities, then click Import entities.
Choose Import discovered entities.
Select the integration to import from.
On the following page, after the integration sync is complete, a list of entities from the integration are displayed. Check the boxes next to any entities you want to import.
Manually creating teams
If you don’t have an identity provider with updated team information, you can create a team manually within Cortex. Because teams are important for effective ownership, it's recommended that you create teams in Cortex even if you don't have a single source of truth for team information.
In Cortex, navigate to Catalogs > Teams, then click Import teams.
Choose Create entities manually.
Adding Cortex-managed teams
You can manually create teams in Cortex and define them in the entity descriptor.
You can also define teams as owners via entity descriptors. See the for more information.
Team entity descriptor
If your entity is a team, you must specify x-cortex-type as team.
The x-cortex-team tag has two main sections: groups and members.
Adding groups to the team entity descriptor
Creating teams via the API
You can create, update, and delete teams using the .
It is possible to edit entities after creating them:
Navigate to the entity's page.
In the upper right corner, click Configure entity.
Make any desired changes.
Note: The only field you cannot edit is the identifier.
At the bottom of the screen, click Save changes.
You can manually create a team member role:
In Cortex, navigate to Settings > Entities > Teams.
Click Add role.
In the "Add role" modal, configure the role:
Role name: Enter the role's name.
Tag: The tag - a unique identifier for the role - automatically populates based on the role name.
Role description: Enter a description of the role.
Enable notifications by default: If notifications are enabled, members with this role will receive relevant updates on Scorecards, Initiatives, and more.
Click Save.
You can apply a role only to manually-created team members. Team members who were imported from an identity integration will retain the role that was imported.
To apply a role:
In Cortex, navigate to Catalogs > Teams.
Click into a team.
In the upper right corner, click Configure entity.
Click Members.
Next to a team member, click the edit icon.
In the side panel, add a new team role.
Click Update.
Under Settings > Entities > Teams, there are several settings relating to teams. You can select which identity providers to use to sync teams and team memberships, configure automatic import from Workday, configure entity editing access, and sync or create roles. Learn more in Entity settings.

Looking to dive deeper? Check out the Cortex Academy course on Scorecards, available to all Cortex customers and POVs.
To create a Scorecard, you must have the admin or manager role, or you must have a custom role that includes the permission Edit Scorecards.
Scorecards evaluate entities, so before using Scorecards, make sure you have entities in your catalogs.
Make sure you have set up any integrations you want to write rules against.
When you create a new Scorecard, you can choose from the following options:
Use a Scorecard template
Start from scratch
Cortex offers the following templates:
Expand the tile below to learn how to create a Scorecard from a template.
When you create a Scorecard, there are two options to set up your Scorecard's evaluation:
Level progression
Establish progressive levels as you add rules to make it obvious which set of rules are the highest priority. Levels allow you to set up a gamified system to encourage developers to make progress toward goals and improve entities' performance.
Set your minimum requirements within the lowest level, and add increasingly higher priority rules to subsequent levels.
For an example demonstrating how levels work, see .
Point-based rules
Use points to assign weighted values to each rule you add to a Scorecard.
You can use point-based rules to set minimum requirements while also encouraging teams to add more metadata. For example, you could assign 1 point for adding a single runbook to an entity, and another point for adding additional runbooks:
If you choose to use only point-based rules in your Scorecard, then you do not need to create levels. You can skip to the next section: Step 3: Create a rule.
There are two methods for building a rule:
Using the form builder
Via the CQL editor
The form is the fastest option, as you can choose from pre-configured rules for each integration. The CQL editor is best when writing complex rules or accessing data from multiple sources.
Expand the tiles below for instructions on each option.
You can repeat the steps above to continue adding rules to your Scorecard. You cannot duplicate a rule across levels, since developers will have already completed that task earlier. It is common, however, to have similar rules with different thresholds if you want developers to progress in stages. For example, a base level might require that the P50 latency for API requests is under 5 seconds, while a higher level may required that the same P50 is under 2 seconds.
After you have finished adding levels and rules to your Scorecard, you are ready to save it as a draft or publish it.
Choose whether to keep your Scorecard in draft form, visible only to users with permission to configure Scorecards. To keep it in draft form, enable the toggle next to Save as draft.
If you choose to keep your Scorecard in draft status, it will not appear in reports or send notifications.
If you choose to publish your Scorecard, it will be visible to all users who have the View Scorecards permission. Notifications, if enabled, will be triggered.
Click Create Scorecard.
After you save the Scorecard, it will automatically evaluate all the entities that apply based on the rules you have configured, and you will be redirected to the Scorecard's page in Cortex.
After you have established Scorecards, there are different steps you can take to continuously improve:
Evaluate progress and take action: Review the Scorecard via reports or by using Cortex MCP, identify trends, and figure out how to take action on the issues you've identified. Learn more in Review and evaluate Scorecards.
Target goals with Initiatives: If you have failing rules, or if you have rules that are a higher priority, you can start using Initiatives to drive progress across the organization. Initiatives allow you to prioritize specific rules within a Scorecard and set deadlines for team members to accomplish tasks. Learn more below.
Initiatives allow you to prioritize specific rules and set deadlines, making sure your team members complete higher priority tasks on time. In a level-based Scorecard, you can set an Initiative that asks your team to complete all rules within a level by a certain date.
You can create an Initiative while viewing a Scorecard. Note that the Scorecard must be published - i.e., not in draft mode - in order to create an Initiative for it.
In the upper right corner, click +Create initiative.
Configure the Initiative form.
For detailed instructions and examples, see the Initiatives documentation.
You can also create an Initiative while viewing reports for the Scorecard under its Reports tab.
When processing a Scorecard, the individual entity evaluations are spread out over the evaluation window you configured. The evaluation will finish before the next evaluation time is reached. Also note that CQL filters require their own independent evaluation, which can increase the time required to process the evaluation.
Use Cortex MCP to quickly gain insights into the performance of your Scorecard. Ask questions in natural language, such as: What is going on with my DORA Metrics Scorecard? or What steps can I take to improve my Eng Intelligence Scorecard scores?
From there, take action to remediate the issues and start meeting your defined standards.
Learn how to get started in Cortex MCP.
When you navigate to a Scorecard's page in Cortex, see high-level information, including the median levels achieved per entity, percent of entities at the highest level, and percent of entities that haven't achieved a level. In the side panel, see basic information, including the total number of services being evaluated, scheduled rules, and the next evaluation time.
When reviewing scores, identify where teams or entities have the most friction. Can you automate any processes via Cortex Workflows to improve efficiency?
Need to show progress to leadership? Click Share in the upper right corner. This copies a link to your clipboard, which you can share with anyone who has access to view this Scorecard in your workspace.
On the Scorecard page, click through each of the tabs to learn more about the Scorecard:
A failed Scorecard rule gives teams actionable goals to make incremental improvements. Teams can focus on addressing the highest-impact failures first, track progress over time, and celebrate measurable wins, which reinforces a culture of improvement.
To remediate failed rules in a Scorecard:
Identify the failing rules
View the Scores tab on a Scorecard page to view a list of failing rules per entity. You can group by level to understand which entities have reached each level of the Scorecard. In this example, the group of entities has met the Bronze level, but they are failing rules for Silver and Gold:
Understand the cause
While viewing scores, click into an entity to open a side panel with more information about why rules are failing.
When , add a failure message to give clear steps on how you can remediate the rule if it fails.
When linking to a Cortex workflow that can be run to remediate a failing rule, Cortex will automatically pass in the entity context to the entity selector (if applicable) on the workflow, so it will be selected by default. You can also set this up manually by appending either the Cortex entity tag or entity ID to the workflow URL from a Scorecard or plugin (e.g. ).
if needed: In some cases, a rule may not apply to an entity. You can request to exempt an entity from the rule.
Track and prioritize issues
Use the to see a prioritized to-do list of failing rules across your owned entities and Scorecards. This helps you focus on addressing the most impactful issues first.
Remediate the issues
Address the underlying issue for each failed rule. This could involve adding missing documentation, configuring a monitoring integration, or any other action required to meet the rule's criteria.
In the example screen shot above, the rule failed because PagerDuty is not configured for the entity. You can follow the to ensure that a PagerDuty service, schedule, or escalation policy is configured in the entity's descriptor YAML.
Re-evaluate
The Scorecard will automatically based on its schedule (or you can manually trigger an evaluation), allowing you to see the progress made and any remaining failing rules.\
When reviewing your Scorecard evaluations, you may notice trends — some teams struggling in specific areas, or some entities often not meeting standards.
In addition to remediating individual rules, you may want to think about how you can improve larger processes to drive excellence in a scalable way across your organization.
Look for frequent challenging areas across teams. For example, is a team consistently failing to add runbooks to new services? Are there any failing rules relating to onboarding processes? When a standard is frequently being missed, it indicates an opportunity to automate that process with a Cortex Workflow.
You can use Workflows to streamline a set of repeatable steps, reducing human error and speeding efficiency for your teams.
For example, you could create a Workflow to streamline the process of Scaffolding new services, and include a User Input step that requires your users to ensure a runbook has been documented.
While viewing a group of entities that are failing rules, you can also look at organizational ways to support your teams or adjust processes.
Team-specific patterns
Are all of the failing entities owned by a newer team?
Ensure that the newer team members are not feeling overwhelmed and have completed any necessary training.
Ensure that the team understands their scope and priorities.
Use Eng Intelligence dashboards and metrics visualizations to identify which parts of the software development lifecycle could be improved per team.
Does one team own more entities than other teams?
Ensure the workload is spread fairly across your teams.
If one teams owns more due to tribal knowledge, it is a signal to ensure team members are documenting their knowledge. It could also help you identify areas to conduct training sessions.
When knowledge has been documented, make sure it is being .
Are some teams or services successful across several areas?
When viewing teams that are successful or entities that meet all of their standards, find ways to recognize these achievements publicly. Public recognition reinforces good practices and motivates your team.
Service lifecycle patterns
Do older, legacy services have low scores, while newer ones align with standards?
This highlights modernization opportunities.
Learn about using Cortex for modernization in the Cortex Academy course "Migrations and Modernizations," available to all customers and POVs.
Adoption over time
Are scores trending upward across the quarter in line with company initiatives?
Tracking Scorecard trends across time shows whether your internal initiatives (like a push for better test coverage) are effective.
To promote specific standards, you can create an Initiative in Cortex based on a Scorecard, which will encourage remediation by a deadline.

is a Git-based version control system from Atlassian. You can use Bitbucket to drive insights into repository details in the Catalog and Scorecard rules.
Integrating Bitbucket with Cortex allows you to:
Discover and track ownership of Bitbucket entities
in Cortex
Follow a workflow with Bitbucket
is an incident response platform that allows developers to manage alerts, schedule rotations, define escalation policies, and more.
Integrating PagerDuty with Cortex allows you to:
Pull in PagerDuty services, on-call schedules, and escalation policies
The on-call user or team will appear in the Current On-call block on an entity's details page.
Once Scorecards are incorporated into your regular engineering workflows, they become production-grade tools. Scorecards set the benchmarks for how your organization defines “good,” which impacts everything from security standards to on-call rotations. Because Scorecards are crucial to achieving and maintaining standards, you may want to employ controlled access and version controlling.
With GitOps editing for Scorecards enabled, you manage Scorecards through , alongside managing the entities in your catalogs. Every Scorecard has its own YAML file. When GitOps is enabled, changes made to Scorecards will appear in .
Learn about the basics in the .
openapi: 3.0.1
info:
title: Sally S
description: Technical writer
x-cortex-tag: employee-sally
x-cortex-type: org-employees
x-cortex-definition:
location: San Diego
department: Engineering{
"type": "object",
"required": [
"location"
],
"properties": {
"location": {
"type": "string"
},
"department": {
"type": "string"
}
}
}{
"location": "San Diego",
"department": "Engineering"
}x-cortex-type: org-employees
x-cortex-definition:
location: San Diego
department: Engineering{
"type": "object",
"required": []
"properties": {}
}openapi: 3.0.1
info:
title: Payments
description: This is my cool domain.
x-cortex-tag: payments-domain
x-cortex-type: domain
x-cortex-owners:
- type: GROUP
name: cortexapps/engineering
provider: GITHUB
inheritance: APPENDkubectl create secret docker-registry cortex-docker-registry-secret \
--docker-server=ghcr.io \
--docker-username={provided by Cortex} \
--docker-password={token provided to you by the Cortex team} \
--docker-email={email address}kubectl create secret generic cortex-key --from-literal api-key=helm install ./helm-chartopenapi: 3.0.1
info:
title: My Service
x-cortex-tag: my-service
x-cortex-type: service
description: This is my cool service.apiVersion: apps/v1
kind: Deployment
metadata:
name: my-name
namespace: my-namespace
annotations:
cortex.io/tag: my-servicek8s.clusters.all((cluster) => cluster.name.matches("""dev-.*"""))k8s.clusters.any((cluster) => cluster.name.matches("prod"))k8s.metadata().labels.any((label) => label.get("ownership") == "ownership_team")k8s.metadata().labels.all((label) => label.containsKey("environment")) == truek8s.metadata().labels.all((label) => label.get("environment")?.matches("prod")") == truek8s != nullk8s.replicas().numAvailable >= 2image: ghcr.io/cortexapps/k8s-agent...app:
# baseURL:
baseURL:
keySecret:
# namespace: exampleNamespaceINFO 1 --- [ scheduling-1] k8sagent : Looking for stateful sets in namespace Error polling argocd rollouts from Kubernetes API
io.kubernets.client.openapi.ApiException:
[...]
at com.brainera.k8sSDKClient.getArgoRollouts(k8sClient.kt:101) ~[app:/na]newrelic != nulljq(newrelic.rawNrql("SELECT percentile(duration) FROM PageView WHERE = '" + newrelic.applications().firstOrNull().name + "' SINCE 3 weeks ago COMPARE WITH 1 week AGO TIMESERIES AUTO"), "[.[].\"percentile.duration\".\"95\"] | add / length") < 500newrelic.rawNrql("SELECT average(`http.server.requests`) FROM Metric WHERE `entity.guid` = '"+newrelic.applications().getOrNull(0)?.guid+"' SINCE 7 DAYS AGO")x-cortex-apm:
newrelic:
applications:
- applicationId: 1234567
alias: Default-App
- applicationId: 8904321
alias: Another-Appx-cortex-apm:
newrelic:
tags:
- tag: tagKey
value: tagValue
alias: Default-Appx-cortex-apm:
newrelic:
tags:
- tag: tagKey
value: tagValue
alias: Default-Appx-cortex-dashboards:
embeds:
- type: newrelic
url: https://chart-embed.service.newrelic.com/example/1a234bc5-d6e7-890f-g123-456h7ij8901 x-cortex-slos:
newrelic:
- id: MjU5ODYxOXxFWFR8U0VSVklDRV9MRVZFTHiw0TI5ODQ
alias: my-default-alias
- id: MjU5ODYxOXxFWFR8U0VSVklDRV9MRVZFTHiw0TI76QB
alias: my-other-alias
- id: MjU5ODYxOXxFWFRAB6VSVklDRV9MRVZFTHiw0TI76QD



Under the Exemptions tab: A list of exempted rules
Under the Progress tab: A graph showing the entity's progress






















newrelic.applications().all(application) => application.apdexScore >= 0.9newrelic.rawNrql("SELECT latest(`process.cpu.usage`) FROM Metric WHERE `entity.guid` = '"+newrelic.applications().getOrNull(0)?.guid+"' SINCE 30 MINUTES AGO TIMESERIES")slos().length > 0slos().all((slo) => slo.passing) == trueTo apply selected owners: On the left side of the list, check the box next to the entities whose recommended owners you want to accept. When you are finished selecting, click Accept recommendations at the top of the list.
The value of provider is the name of the integration that the group is coming from. The available list is:
ACTIVE_DIRECTORY
AZURE_DEVOPS
BAMBOO_HR
CORTEX: Use when referring to a team defined in Cortex; these teams do not map to identities from a connected integration.
GITHUB
GITLAB
OKTA
OPSGENIE
SERVICE_NOW
WORKDAY
name is a case-sensitive field that refers to the following:
if your provider is CORTEX, name corresponds to the x-cortex-tag for the Cortex team you want to identify as an owner
otherwise, name corresponds to the upstream identifier of your owner from your integration
If this option isn't displayed, make sure you have enabled UI editing for entities.
Click the Owners tab, then click +Add next to Teams or Users.
Add team:
Select a team from the dropdown menu, then click Add.
Add user:
Select a user from the dropdown menu, then click Add.
You can also add a user who is not listed in Cortex. To do this, enter an email address into the Email address field, then click Add.








Optionally enter a JQ mapping into the Annotation mapping field.
Click Save mapping.
Note that Cortex looks at the top-level metadata annotations on the Deployment object itself (metadata.annotations), not the pod template annotations (spec.template.metadata.annotations).
If your automapping is not working as expected, make sure the annotation mapping is at the correct default absolute path of .metadata.annotations."cortex.io/tag", or update the annotation mapping in the K8s configuration page to match the exact absolute path of the Cortex tag.
Example
Let's say, for example, your deployment.yaml includes my.service as the cortex.io/tag:
If this deployment should be mapped to a Cortex entity with the tag my-entity, you can enter the following JQ expression to convert all periods in the deployment annotation tag to dashes:
When you are finished, click Save.
Once the list is saved, Cortex will discover all Kubernetes resources with metadata labels with the following criteria:
The resource's spec metadata key contains any of the specified labels
The key values match a Cortex entity tag
Example
For example, let's say you have two Cortex entities (example and entity), and the following Kubernetes JSON blob:
By default, example and entity will have no Kubernetes resource mappings. If the list of metadata labels is set to ["app"], then entity example will be associated with "Sample Kubernetes resource." If the list is set to ["app", "another"], then both example and entity will be associated with the resource.
ArgoCD Rollout
StatefulSet
CronJob
identifier
namespace/name as found in Kubernetes
✓
cluster
The name of the cluster, which is set when deploying the agent


If you have a large volume of entites, click Filter in the upper right corner of the results list to select and apply entity type filters.
At the bottom of the page, click Next step.
Edit the details for the entity:
Type: Select Team.
Name: Enter a human readable name for your team.
Identifier: This field is auto-populated based on your entity name. It is a unique identifier for your entity. This is also known as the x-cortex-tag.
Description: Enter a description of the team to help others understand its purpose.
Groups: Select your entity.
Members: Select members of your team. Team members will be marked as owners of entities and receive notifications about entities owned by the team if notifications are enabled.
Links: Add links to external documentation, such as runbooks, docs, logs, or custom categories.
Slack channels: Link the team's associated Slack channel. If , the team will receive notifications here.
You must have the configured before linking a channel.
Parents and Children: Define parent and children teams. This is where you configure the hierarchy for your entity. These can be visualized in the .
On-call: Configure the on-call service associated with this team. When selected, you will see the latest on-call information displayed on the team's details page.
If you selected more than one entity: After the first entity is configured, click the name of the next entity on the right to navigate to the detail editor for that entity.
Click Confirm import.
Configure the team details:
Type: Select Team.
Name: Enter a human readable name for your team.
Identifier: This field is auto-populated based on your entity name. It is a unique identifier for your entity. This is also known as the x-cortex-tag.
Description: Enter a description of the team to help others understand its purpose.
Groups: Select your entity.
Members: Select members of your team. Team members will be marked as owners of entities and receive notifications about entities owned by the team if notifications are enabled.
Links: Add links to external documentation, such as runbooks, docs, logs, or custom categories.
Slack channels: Link the team's associated Slack channel. If , the team will receive notifications here.
You must have the configured before linking a channel.
Parents and Children: Define parent and children teams. This is where you configure the hierarchy for your entity. These can be visualized in the .
On-call: Configure the on-call service associated with this team. When selected, you will see the latest on-call information displayed on the team's details page.
Click Confirm import.
Once you've created a team, you can view it on the Teams page within the hierarchy. If you haven't added parents or children, you can disable View as hierarchy to see the list of all teams.
Use groups to link your team entity with a team on a different platform that you have integrated with Cortex. You can only link one group to a team entity.
For example, you can specify:
Under groups, when you specify okta-security-team, your team will contain all the members from your okta-security-team.
Now, if you specify the okta-security-team in your x-cortex-owners on any of your other entities, they will automatically recognize example-team as a team that owns their entity.
Adding team members to the team entity descriptor
members can be used to add individual members to your team when you have a use case for a team entity that doesn't correspond exactly to a team on one of your integrations. Members support roles. For example, the following entity includes a member who has the product-manager role and a member who has both the engineering-manager role and manager role:
After specifying the YAML example above, your team now will contain Product Manager and Engineering Manager. If [email protected] or [email protected] were to correspond with the email of an actual account in Cortex, they would start seeing example-team being displayed as a team that they're a part of (i.e., it would start showing up in their Mine tab in catalogs that contain teams).
Roles must be defined for your workspace in your Entity Settings page, under the "Teams" tab.
Team children
You can define a list of other teams as children, allowing you to represent a hierarchy of how your teams are modeled across your workspace, using the x-cortex-children tag.
This hierarchy is available to look at in the Teams catalog page.
The hierarchy of entities in Cortex is based on that hierarchy being defined in the entity's YAML file; Cortex does not set hierarchies based on a YAML file's location in your repository.
Team parents
Team children allow you to define the team relationship from the top-down, but in some cases it may be easier to define the team hierarchy from the bottom-up. For these cases, x-cortex-parents can be added to any entity's YAML to define its parents.
Example cortex.yaml
Note: the YAML definition for a team entity can take file names other than cortex.yaml or cortex.yml; see the GitOps example repository structure.





Evaluation window: By default, Scorecards are evaluated every 4 hours. If you would like to evaluate Scorecards less frequently, you can override the evaluation window and enter a new number.
If a Scorecard is evaluating such a large number of entities that it cannot complete the evaluation in a 4-hour window without invoking rate limits, then a longer evaluation window is recommended.
You will also be able to manually trigger an evaluation when needed.
Enable notifications: Choose whether to enable notifications.
If notifications are enabled, users who own entities being evaluated by this Scorecard will receive alerts when there are relevant updates on the Scorecard and any corresponding initiatives.
Notify when scores drop: When enabled, you will be notified any time a score drops from the last time the Scorecard was evaluated.
Enable exemptions: Choose whether to enable Scorecard exemptions. If not set, it defaults to true.
See Scorecard rule exemptions for more information.
Enable auto-approval exemptions: Choose whether to enable auto-approving of Scorecard rule exemptions. If not set, it defaults to false.
Enable user-specific notifications: Add a field to allow your users to notify a specific user to approve a rule exemption request rather than all Admins.
If this field is enabled, Scorecard notifications will also be enabled automatically.
You can also include a CQL expression to make your entity type selection.
Rule name: Enter a descriptive name. Names make it easier to understand the outcome of the rule without having to read the CQL expression.
This option can be used when a group of entities should be evaluated by the Scorecard as a whole, but a specific rule in the Scorecard does not apply to that group.
See Scorecard rule filters for more information on configuring a filter.
Points: Enter how many points this rule is worth.
You can use points to signify each rule's importance. Rules worth more points are more critical than those with fewer points.
Schedule evaluation start date: If you want to schedule the evaluation of a rule to start on a specific date, schedule a start date here. When the field is blank, the rule will take effect immediately. If a start date is provided, the rule will take effect at the start of the specified day (UTC).
This is helpful when you want users to be aware of an upcoming rule, but you do not want to evaluate the Scorecard yet based on that rule.
Scheduled rules are visible to all users and will be included in the weekly team and user reports to help with socialization.
Users can choose to when a scheduled rule is added to a Scorecard evaluating an entity they own, and they can receive reminders before a scheduled rule impacting an owned entity goes into effect.
This option can be used when a group of entities should be evaluated by the Scorecard as a whole, but a specific rule in the Scorecard does not apply to that group.
See Scorecard rule filters for more information on configuring a filter.
Points: Enter how many points this rule is worth.
You can use points to signify each rule's importance. Rules worth more points are more critical than those with fewer points.
Schedule evaluation start date: If you want to schedule the evaluation of a rule to start on a specific date, schedule a start date here. When the field is blank, the rule will take effect immediately. If a start date is provided, the rule will take effect at the start of the specified day (UTC).
This is helpful when you want users to be aware of an upcoming rule, but you do not want to evaluate the Scorecard yet based on that rule.
Scheduled rules are visible to all users and will be included in the weekly team and user reports to help with socialization.
Users can choose to when a scheduled rule is added to a Scorecard evaluating an entity they own, and they can receive reminders before a scheduled rule impacting an owned entity goes into effect.









View information about pull requests in the engineering homepage
Use Bitbucket metrics in Eng Intelligence to understand key metrics and gain insight into services, incident response, and more
Create Scorecards that track progress and drive alignment on projects involving your Bitbucket repositories
There are multiple options for integrating with Bitbucket:
Cloud: Using a workspace token (recommended), the Cortex Atlassian app, or an app password.
On-prem: Using Basic auth or using OAuth
You can also integrate using Cortex Axon Relay, a relay broker that allows you to securely connect your on-premises Bitbucket data.
See the tabs below for instructions on the method you choose.
Configure Cortex with Bitbucket using a workspace token
Step 1: Generate a workspace token in Bitbucket
In Bitbucket, navigate to Settings > Workspace settings > Access tokens.
Create a workspace-level access token. Include the following scopes:
Repositories: Read
Pull requests: Read
Step 2: Configure the integration in Cortex
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Bitbucket.
For the configuration type, select Cloud (workspace token).
Step 3: Set your Bitbucket workspace
On the in Cortex, next to your integration's alias, click Add workspace.
In the "Workspace configuration" modal, enter your Workspace name.
You can find this in Bitbucket under Settings > Workspace settings.
Click
Configure Cortex with Bitbucket using the Atlassian app
Step 1: Install the Cortex Atlassian app
Follow the for the Cortex app.
Step 2: Configure the integration in Cortex
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Bitbucket.
Configure Cortex with Bitbucket using an app password
Step 1: Create an app password
Follow Atlassian's documentation to .
Make sure to give the app password the following minimum permissions: Repositories: Admin, Repositories: Read, Pull requests: Read
Configure Cortex with Bitbucket using a on-premises basic auth
Step 1: Create an app password
Follow Atlassian's documentation to .
Make sure to give the app password the following minimum permissions: Repositories: Admin, Repositories: Read, Pull requests: Read
Configure Cortex with Bitbucket on-premises using OAuth
Prerequisites
To configure this integration with on-prem OAuth, you must be running a self-hosted Bitbucket instance with Bitbucket Server or Data Center version 7.20 or higher.
Step 1: Set up an application link in Bitbucket
In your Bitbucket server, navigate to Settings > System > Application Links > Create Link.
Configure the application link:
Configure Bitbucket with Cortex Axon Relay
See for instructions. Make sure to follow the Bitbucket-specific instructions for the docker-compose.yml file.
Once you save your configuration, you'll see it listed on the integration's settings page in Cortex. If you’ve set everything up correctly, you’ll see the option to Remove Integration in Settings.
You can also use the Test all configurations button to confirm that the configuration was successful. If your configuration is valid, you’ll see a banner that says “Configuration is valid. If you see issues, please see documentation or reach out to Cortex support.”
Configure the integration for multiple Bitbucket accounts
The Bitbucket integration has multi-account support. You can add a configuration for each additional by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the Bitbucket page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
Cortex supports mapping multiple identities for a single user if you have multiple configurations of Bitbucket. See the Identity mapping documentation for more information.
If you are a part of multiple projects in Bitbucket but you only want to show repositories for a specific set of projects, you can specify the projects in Cortex:
Navigate to the Bitbucket integration settings page.
Click the pencil icon in the row containing the Bitbucket configuration you want to edit.\
Under Project names, select which projects you want to include.
At the bottom of the side panel, click Save.
To use webhooks for GitOps functionality, you need to set a secret token on the Bitbucket Settings page. This helps Cortex identify that the webhook event is valid. Make sure to enter the same secret when configuring the webhook on Bitbucket Server. \
See the Create services documentation for instructions on importing entities.
Set repository details
By specifying the x-cortex-git field in your Cortex entity descriptor, you'll be able to see Git information in the entity page, including the top language, recent commits, and top contributors.
repository
org/repo as defined in Bitbucket
true
basepath
If the entity is in a monorepo (e.g. in a subdirectory), use this field to define the subdirectory
false
alias
Alias is optional and only relevant if you have opted into multi account support
false
The value for repository should be the workspace/repo as defined in Bitbucket.
Ownership
You can define the following block in your Cortex entity descriptor to add your Bitbucket teams.
type
Ownership type; must be defined as group for Bitbucket teams
✓
name
Bitbucket team name
✓
provider
Name of integration (in this case, BITBUCKET)
✓
description
Description for the Bitbucket team
Cortex maps users' email addresses to discovered Bitbucket accounts, so you never need to define email ownership in an entity descriptor.
You can confirm users' Bitbucket accounts are connected from Bitbucket identity mappings in settings.
The Bitbucket integration populates the Repository block on an entity's details page. For cloud configurations, it also populates the Language block. If a Bitbucket team has been defined as the owner for an entity, it will also appear in the Owners block.
In the Recent activity preview, you'll find the recent commits and releases.
On an entity's Events page, you can find all of the commits and releases associated with that entity. Each is hyperlinked to the commit or release page in Bitbucket and includes a timestamp.
If a Workflow applies to a given entity, any actions you can perform are available under the Workflows link in the side panel of an entity.
You can access more detailed information pulled from Bitbucket in the Repository link in the sidebar. At the top of the repository page, see the repositories associated with that entity. For cloud configurations, you can also see the most-used language in files for that entity. In the Top contributors block, you'll find the three users who have contributed the most code and the number of their contributions.
In the Commits section, you'll find the 10 most recent commits and metadata about each. Below Commits is the Recent releases section, which includes the 5 most recent releases.
The Bitbucket integration enables Cortex to pull information about pull requests and work items into the homepage. You can find your open pull requests and any pull requests assigned to you for review.
Pull requests from Bitbucket are refreshed every 5 minutes.
The Eng Intelligence tool also uses pull request data from Bitbucket to generate metrics:
Average PR open to close time
Avg time to first review
Avg time to approval
PRs opened
Weekly PRs merged
Avg PRs reviewed/week
You can read more about how Eng Intelligence tracks metrics for teams and users in the Eng Intelligence walkthrough.
With the Bitbucket integration, you can create Scorecard rules and write CQL queries based on Bitbucket details.
See more examples in the CQL Explorer in Cortex.
Cortex conducts a background sync of Bitbucket identities every day at 10 a.m. UTC. Repositories are refreshed every day at 2 p.m. UTC.
Rules are failing saying that I don't have file x, but I verified that the file exists.
We always use the default branch for file existence checks. Make sure that the file is present in the default branch.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Trigger incidents in PagerDuty directly from Cortex
Automatically surface the most vital information about entity health and metadata when an incident is triggered by using Cortex's On-Call Assistant tool
The On-Call Assistant automatically notifies users via Slack when an incident is triggered. The notifications include runbooks, links, dependencies, and key information about the affected entity.
View incidents from PagerDuty in an entity's event timeline
View on-call information from PagerDuty in the engineering homepage
Use PagerDuty metrics in Eng Intelligence to understand key metrics and gain insight into services, incident response, and more.
Create Scorecards that track progress and drive alignment on projects involving your on-call schedules and alerts
Before getting started:
Create a PagerDuty API key.
When adding the API key, you have the option to set read or write permissions.
Read: Enables Cortex to read any and all data from PagerDuty
Write: Allows users to from an entity page in Cortex, and enables On-Call Assistant
To use PagerDuty in Cortex, enable the following permissions:
incident.write to create incidents
escalation_policies.write to create escalation policies
In Cortex, navigate to the PagerDuty settings page:
Click Integrations from the main nav. Search for and select PagerDuty.
Click Add configuration.
Configure the integration:
API key: Enter the API key you created in PagerDuty.
If the Read-only API key option is togged off, Cortex will use assume the provided API key has write permissions.
Click Save.
If you’ve set everything up correctly, you’ll see the option to Remove Integration in settings.
You can also use the Test configuration button to confirm that the configuration was successful. If your configuration is valid, you’ll see a banner that says “Configuration is valid. If you see issues, please see documentation or reach out to Cortex support.”
At this stage, you can enable the Cortex On-call Assistant, which notifies users via Slack when an incident is triggered in PagerDuty. See the documentation for instructions: On-Call Assistant.
Note that On-Call Assistant will only work for service-level PagerDuty registrations since these notifications are related to affected services.
By default, Cortex will use the Cortex tag (e.g. my-entity) or its name as the "best guess" for PagerDuty services. For example, if your Cortex tag is my-entity, then the corresponding service in PagerDuty should also be my-entity.
If your PagerDuty services don’t cleanly match the Cortex tag or name, you can override this in the Cortex entity descriptor.
Cortex recommends setting up PagerDuty at the service level by registering service entities with PagerDuty services, rather than configuring team entities with a PagerDuty schedule.
If PagerDuty is set up on a service level, you can see current on-call information listed within a given service's page. If PagerDuty is set up on the team level, you will only be able to view on-call rotation information from a team page.
Other benefits to setting up PagerDuty on a service level include:
Structuring PagerDuty 1-1 with services enables better alert routing and analytics, something that organizations struggle more with when PagerDuty is set up on a team level.
With a service-level setup, it’s easier to enforce all services to have a compliant on-call policy enacted in PagerDuty, especially when making use of Scorecards.
The service-level setup is less reliant on team members tagging incidents with service information because services and incidents are already linked.
You will gain the ability to get data from your Cortex catalog into PagerDuty, such as tier/criticality. By tying the service entities in the catalog with those in PagerDuty, you can automate processes and streamline severity protocols.
If you want to only view on-call data for entities, and you do not want incidents displayed in Cortex, you can register the escalation policy ID for an entity.
For a given entity, you can define the PagerDuty service, schedule, or escalation policy within the entity’s YAML. You can only set up one of these three options per entity.
Each of these has the same field definitions.
id
PagerDuty ID for service, schedule, or escalation policy
✓
type
SERVICE, SCHEDULE or ESCALATION_POLICY
✓
Find the service ID value in PagerDuty under Configuration > Services. The URL for the service will contain the ID, for example: https://cortexapp.pagerduty.com/services/. You can only configure one service ID per entity.
Find a schedule ID in PagerDuty under People > On-call schedules. Click the desired schedule to view its ID in the URL, for example: https://cortexapp.pagerduty.com/schedules#. You can only configure one schedule per entity.
Find the escalation policy ID in PagerDuty under People > Escalation Policies. Click the desired policy to view its ID in the URL, for example: https://cortexapp.pagerduty.com/escalation_policies#. You can only configure one escalation policy per entity.
When linking a Cortex entity to a PagerDuty escalation policy, only on-call information will be surfaced in Cortex — incidents will not be shown. This is a useful alternative for teams that want to suppress incident visibility while displaying call schedules.
You can only set up one of the three options above per entity.
Cortex maps email addresses in your PagerDuty instance to email addresses that belong to team members in Cortex. When identity mapping is set up, users will be able to see their personal on-call status from the developer homepage.
Once the PagerDuty integration is set up, you’ll be able to view current on-call information in the "on-call" block on an entity details page. In the left sidebar of an entity, click On-call & incidents to view on-call information, escalation policy, service, and incidents.
The escalation policy and PagerDuty service details are hyperlinked to the corresponding pages in your PagerDuty instance.
Click Events in an entity's sidebar to view recent events pulled in from PagerDuty.
The PagerDuty integration enables Cortex to pull on-call information into the on-call block on the Engineering homepage. On-call data from PagerDuty is refreshed every 60 minutes.
Cortex also pulls in metrics from PagerDuty for Eng Intelligence. This tool will display MTTR, incidents opened, and incidents opened per week.
If you have a Slack integration set up, you can also use the /cortex oncall Slack Bot command to retrieve current on-call information. This feature works for both services and teams with registered PagerDuty schedules or escalation policies.
With the PagerDuty integration, you can create Scorecard rules and write CQL queries based on incidents, escalations, and on-call metadata.
See more examples in the CQL Explorer in Cortex.
As described above under Editing the entity descriptor, a given entity can have a PagerDuty service, schedule, or escalation policy defined. Only entities with a PagerDuty service defined will include the option to trigger an incident directly from Cortex.
Your PagerDuty API key must include the write permission in order to trigger incidents from an entity.
While viewing an entity in Cortex, follow these steps to trigger an incident in PagerDuty:
In Cortex, navigate to an entity. On the left side of an entity details page, click On-call & incidents.
In the upper right side of the entity's "On-call" page, click Trigger incident.
Configure the incident modal:
Summary: Enter a title for the incident.
Description: Enter a description of the incident.
Severity: Select a severity level.
At the bottom of the modal, click Trigger incident.
A confirmation screen will appear. In the confirmation, click the link to view the incident in PagerDuty.
PagerDuty performs the following background jobs:
On-call: On-call information displayed on the developer homepage is refreshed every 60 minutes.
Services and incidents: Services used for automapping and active incidents viewable in the catalog are fetched approximately every 5 minutes, or however long the refresh takes.
Users: User data for identity mapping is synced daily at 10 a.m. UTC.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Navigate to Settings > GitOps then click the Scorecards tab.
Toggle on the Enable GitOps for Scorecard editing option.
When GitOps for Scorecard editing is enabled:
All Scorecard editing via the Cortex UI is disabled, regardless of whether the Scorecard was created via Git or the UI.
You will still be able to create and delete Scorecards via the Cortex UI.
To edit any Scorecard when GitOps is enabled, you must update the definition in the corresponding YAML file in your Git repository.
You can also configure an allowlist to determine which repositories you import Scorecards from.
You can create a Scorecard in the Cortex UI then convert it to a YAML file, or you can create a Scorecard from scratch. See an example Scorecard YAML file below.
The recommended location for Scorecards is in their own repository, separate from catalog entities, at the repository's root directory within .cortex/scorecards. Note that it is not recommended to put Scorecard definitions in a service repository as Scorecards are not meant to be 1:1 with catalog entitites.
For example, a simple repository might have the following structure:
Any file found within the .cortex/scorecards directory will be automatically picked up and parsed as a Scorecard.
You may have Scorecards in Cortex that were created via the UI before you started working via GitOps. To convert an existing Scorecard into code:
Navigate to the Scorecard's details page in Cortex.
Click the vertical ellipsis (⋮) at the top of the page, then click Export Scorecard YAML.\
Add the Scorecard's YAML file to your Git repository.
When GitOps for Scorecard editing is enabled and your Scorecard has been converted to a YAML file in your Git repository, you will no longer be able to edit it via the Cortex UI.
The dora-metrics-scorecard.yaml descriptor file might look something like this:
name
description
name
The human-readable name of the Scorecard
tag
A unique slug for the Scorecard consisting of only alphanumeric characters and dashes
description
A human-readable description of the Scorecard
draft
Whether or not the Scorecard is a draft
notifications
Notifications settings for the Scorecard
ladder
The ladder to apply to the rules
name
description
enabled
Whether or not to include the Scorecard in notifications
scoreDropNotificationsEnabled
Whether to notify about entities' scores that dropped after each evaluation of this Scorecard
name
description
enabled
Whether or not rule exemptions are enabled for Scorecard
autoApprove
Whether or not rule exemptions are auto approved for Scorecard
userSpecificNotifications
Whether user-specific rule exemption notifications are enabled for Scorecard
name
description
levels
The levels of the ladder
name
description
name
The human-readable name of the level
rank
The rank of the Level within the ladder. Higher rank is better.
description
A human-readable description of the level
color
The hex color of the badge that is displayed with the level
name
description
title
The human-readable name of the Rule
expression
The CQL expression to evaluate; must evaluate to a boolean
identifier
Identifier of the rule, unique within Scorecard scope. Can be configured to a custom value of your choice. If omitted, we will automatically generate a value.
description
A human-readable description of the Rule
weight
The number of points this Rule provides when successful
failureMessage
A human-readable message that will be presented when the Rule is failing
Note: One of types, groups, or query must be present for it to be considered a valid filter.
name
description
kind
The kind of filter to create. Currently only supports "GENERIC"
types
Types filter (to include / exclude specific types)
groups
Groups filter (to include / exclude specific groups)
query
A CQL query; only entities matching this query will be evaluated by the Scorecard
Note: Only one of include or exclude can be specified at a time.
name
description
include
List of types to include in set of entities
exclude
List of types to exclude in the set of entities
name
description
include
List of groups to include in set of entities
exclude
List of groups to exclude in the set of entities
name
description
window
By default, Scorecards are evaluated every 4 hours. That default can be changed under Settings > Scorecards > Default evaluation window. If you would like to evaluate Scorecards less frequently, you can override the evaluation window. This can help if you're encountering problems with rate limits. Note that Scorecards cannot be evaluated more than once per minimum set in Settings > Scorecards > Minimum evaluation window.
is a project management tool that helps developers track and manage bugs and work items.
By integrating Jira with Cortex, you can drive improvements and coordinate issue management across teams. Through the integration, you can create Jira work items directly in Cortex based on an Initiative's action items. The integration also allows you to enhance insights into a number of key values for your entities:
Customer facing incidents
Security tickets
is a messaging and collaboration platform that makes it easy to communicate with your team and work together efficiently on projects.
Integrating Cortex with Slack allows you to:
Quickly find the relevant Slack channel to communicate with the right team, allowing for easier collaboration on projects and faster communication during an incident
Slack channels appear in the "Owners" block on .
x-cortex-owners:
# Groups can be pulled from various integrations
- type: group
name: my-team
provider: CORTEX
description: This is a description for this owner # optional
- type: email
email: [email protected]
description: This is a description for this owner # optionaljq(k8s.spec(), ".[].template.spec.containers[].resources.requests.cpu") != nulljq(k8s.spec(), ".[].template.spec.containers[].ports[].protocol") == "TCP"metadata:
name: my-name
namespace: my-namespace
annotations:
cortex.io/tag: my.service.metadata.annotations."cortex.io/tag" | gsub("\\."; "-"){
"name": "Sample Kubernetes resource",
"metadata": {
"labels": {
"app": "example",
"another": "entity"
}
}
}x-cortex-k8s:
deployment:
- identifier: namespace/name
cluster: dev
- identifier: experiment/scratch
cluster: dev
- identifier: default/cortex
cluster: prodx-cortex-k8s:
argorollout:
- identifier: namespace/name
cluster: devx-cortex-k8s:
statefulset:
- identifier: namespace/name
cluster: devx-cortex-k8s:
cronjob:
- identifier: namespace/name
cluster: devopenapi: 3.0.1
info:
title: Payments Team
description: This is my cool team.
x-cortex-tag: payments-team
x-cortex-type: teamopenapi: 3.0.1
info:
title: Example Team
description: My Cool Team
x-cortex-type: team
x-cortex-tag: example-team
x-cortex-team:
groups:
- name: okta-security-team
provider: OKTAopenapi: 3.0.1
info:
title: Example Team
description: My Cool Team
x-cortex-type: team
x-cortex-tag: example-team
x-cortex-team:
members:
- name: Product Manager
email: [email protected]
notificationsEnabled: true
roles:
- tag: product-manager
- name: Engineering Manager
email: [email protected]
notificationsEnabled: true
roles:
- tag: engineering-manager
- tag: manager openapi: 3.0.1
info:
title: Payments
description: This is my cool team.
x-cortex-tag: payments-team
x-cortex-type: team
x-cortex-children:
- tag: child-team-1
- tag: child-team-2openapi: 3.0.1
info:
title: Payments
description: This is my cool team.
x-cortex-tag: payments-team
x-cortex-type: team
x-cortex-parents:
- tag: parent-team-1
- tag: parent-team-2openapi: 3.0.1
info:
title: Chat Team
description: Chat team.
x-cortex-tag: chat-team
x-cortex-type: team
x-cortex-team:
groups:
- name: okta-chat-team
provider: OKTA
members:
- name: Product Manager
email: [email protected]
notificationsEnabled: true
- name: Engineering Manager
email: [email protected]
notificationsEnabled: true
x-cortex-children: # children can be of type team
- tag: chat-infra-team
- tag: chat-sre-team
x-cortex-slack:
channels:
- name: chat-team
notificationsEnabled: true
description: This is a description for the chat-team Slack channel # optional
x-cortex-oncall:
pagerduty:
id: ASDF2345
type: SCHEDULEgit.numOfRequiredApprovals() >= 1git != nullgit.percentBuildSuccess() > 0.9x-cortex-git:
bitbucket:
repository: /
basepath: myService # optional
alias: myApp # optionalx-cortex-owners:
- type: group
name: Team Name
provider: BITBUCKET
description: This is a description for this Bitbucket team that owns this entity.oncall != nulloncall.numOfEscalations() >= 2oncall.details().type == "schedule"oncall.details().id.matches("Legacy*") == falsex-cortex-oncall:
pagerduty:
id: ASDF1234
type: SERVICEx-cortex-oncall:
pagerduty:
id: ASDF1234
type: SCHEDULEx-cortex-oncall:
pagerduty:
id: ASDF1234
type: ESCALATION_POLICY.
├── .cortex
│ └── scorecards
│ ├── dora.yml
│ └── performance.yml
└── src
└── index.js
└── ...name: DORA Metrics
tag: dora-metrics
description: >-
[DORA metrics](https://www.cortex.io/post/understanding-dora-metrics) are used by DevOps teams to measure their performance.
The 4 key metrics are Lead Time for Changes, Deployment Frequency, Mean Time to Recovery, and Change Failure Rate.
draft: false
notifications:
enabled: true
scoreDropNotificationsEnabled: false
exemptions:
enabled: true
autoApprove: false
userSpecificNotifications: false
ladder:
levels:
- name: Bronze
rank: 1
description: Pretty good
color: "#c38b5f"
- name: Silver
rank: 2
description: Very good
color: "#8c9298"
- name: Gold
rank: 3
description: Excellent
color: "#cda400"
rules:
- title: Ratio of rollbacks to deploys in the last 7 days
expression: >+
(deploys(lookback=duration("P7D"),types=["ROLLBACK"]).length /
deploys(lookback=duration("P7D"),types=["DEPLOY"]).length) > 0.05
identifier: 3c42fa96-b422-30a4-b75a-f8b1cc233408
description: Change Failure Rate
weight: 25
failureMessage: Less than 95% of deployments in the last 7 days were successful
level: Gold
- title: Incident was ack'ed within 5 minutes
expression: oncall.analysis(lookback = duration("P7D")).meanSecondsToFirstAck <= 300
identifier: 8713f2c0-f161-3688-9f99-bcfaab476b63
description: MTTA (Mean time to acknowledge)
weight: 25
failureMessage: Incidents in the last 7 days were not ack'ed
level: Silver
- title: Last commit was within 24 hours
expression: git.lastCommit().freshness = 7
identifier: a16b7eeb-545b-359e-81a7-3946baacdd4b
description: Deployment Frequency
weight: 25
failureMessage: No deployments in the last 7 days
filter:
kind: GENERIC
types:
include:
- service
groups:
include:
- production
evaluation:
window: 4

rules
A list of rules that are evaluated each time the Scorecard is evaluated
filter
Enables the ability to exclude entities from being evaluated by this Scorecard
evaluation
Enables the ability to change the evaluation window for this Scorecard
level
The name of the level this rule is associated with; can be null even when a ladder is present
filter
Enables the ability to exclude entities from being evaluated for this rule
effectiveFrom
Date when the rule starts being evaluated (e.g. 2024-01-01T00:00:00Z)




schedules.write to create schedulesservices.write to create services
teams.write to create teams
oncall.usersWithoutContactMethods(allowed=["SMS", "PHONE"]).length == 0oncall.usersWithoutContactMethods(allowed=["EMAIL"]) > 0oncall.usersWithoutContactMethods(allowed=["EMAIL"], onlyCurrentOncall=true) > 0oncall.analysis(lookback = duration("P7D"), priority = ["P1", "P2"]).meanSecondsToFirstAck <= 300oncall.analysis(lookback = duration("P7D"), priority = ["P1"]).meanSecondsToResolve < 3600oncall.analysis(lookback = duration("P7D")).totalIncidentCount == 0oncall.incidents(lookback = duration("P1M")).length < 15oncall.incidents(lookback=duration("P1M")).filter((incident) => incident.status.matches("TRIGGERED|ACKNOWLEDGED")).length < 1oncall.incidents(lookback=duration("P1M")).filter((incident) => incident.createdAt.until(incident.resolvedAt) > duration("P-2D")).length < 2Account alias: Enter an alias for the account. Aliases are used to tie service registrations to different configuration accounts.
Token: Enter the workspace token you generated in Bitbucket.
Click Save.
Click Add Bitbucket configuration.
For the configuration type, select select Atlassian app.
Configure the "Add Bitbucket configuration" form:
Account alias: Enter an alias for the account. Aliases are used to tie service registrations to different configuration accounts.
Click Save.
You will be redirected to the Bitbucket Settings page in Cortex.
Step 3: Connect to Atlassian from Cortex
On the Bitbucket settings page in Cortex, click Atlassian Application.
In the popup that appears, click Grant access to authorize Cortex access to your Atlassian Workspace.
In Cortex, navigate to the Bitbucket settings page.
Click Integrations from the main nav. Search for and select Bitbucket.
Click Add configuration.
For the configuration type, select Cloud (basic auth).
Configure the "Add Bitbucket configuration" form:
Account alias: Enter an alias for the account. Aliases are used to tie service registrations to different configuration accounts.
Username: Enter your Bitbucket username.
You can find this in Bitbucket under Personal settings > Account settings > Bitbucket profile settings
Click Save.
You will be redirected to the Bitbucket Settings page.
Step 3: Set your Bitbucket workspace
On the Bitbucket Settings page in Cortex, next to your integration's alias, click Add workspace.
In the "Workspace configuration" modal, enter your Workspace name.
You can find this in Bitbucket under Settings > Workspace settings.
Click Save.
In Cortex, navigate to the Bitbucket settings page.
Click Integrations from the main nav. Search for and select Bitbucket.
Click Add configuration.
For the configuration type, select On-prem (basic auth).
Configure the "Add Bitbucket configuration" form:
Account alias: Enter an alias for the account. Aliases are used to tie service registrations to different configuration accounts.
Host: Enter your Bitbucket on-prem host, e.g., https://bitbucket.example.com.
Click Save.
Note: When using an on-premises configuration of Bitbucket, the language does not populate on entity detail pages.
For the application type, select "External Application."
For the direction, select "Incoming."
For the redirect URL:
Default configuration: Enter the URL of your Cortex instance and /oauth/internal/bitbucket.
Non-default configuration: Enter the URL of your Cortex instance and /oauth/internal/bitbucket/.
For the Permission, select Projects: Admin and Repositories: Admin.
Click Save.
Copy the client ID and client secret. You will need these in the next steps.
Step 2: Configure the integration in Cortex
In Cortex, navigate to the Bitbucket settings page.
Click Integrations from the main nav. Search for and select Bitbucket.
Click Add configuration.
For the configuration type, select On-prem (OAuth).
Configure the "Add Bitbucket configuration" form:
Account alias: Enter an alias for the account. Aliases are used to tie service registrations to different configuration accounts.
Host: Enter your Bitbucket on-prem host, e.g., https://bitbucket.example.com.
Click Save.
Note: When using an on-premises configuration of Bitbucket, the language does not populate on entity detail pages.






It is possible to configure the integration with a Jira Cloud instance or a self-hosted Jira instance (using either basic auth or OAuth). You can also use Cortex Axon Relay to securely integrate your on-premises data. See the tabs below for instructions on each option.
Jira Cloud
Prerequisites
Before configuring Cortex with Jira Cloud:
Create a Jira API token. To generate a token, you must have the Browse users and groups permissions in Jira and access to the needed Jira projects.
If you are using a scoped token, you will need your Atlassian Cloud ID. Scoped tokens must include the following scopes:
Read: jira-work, jira-user, project-category:jira, project:jira, project-version:jira, project.property:jira, project.component:jira, issue-type:jira, issue-type-hierarchy:jira, user:jira, avatar:jira, project.avatar:jira, application-role:jira
Write: jira-work
Configure the integration in Cortex
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select Jira.
Click Add configuration. then select Cloud for the integration type.
Jira on-prem (Basic)
Prerequisite
If you're using a self-hosted instance of Jira, you'll need to verify that your Cortex instance is able to reach the Jira instance. We route our requests through a static IP address. Reach out to support at to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your Jira instance.
Configure the integration in Cortex
In Cortex, navigate to the :
Jira on-prem (OAuth)
Prerequisites
To integrate Cortex with Jira using OAuth, you must be running a self-hosted Jira instance with Jira server version 8.22 or higher.
If you're using a self-hosted instance of Jira, you'll need to verify that your Cortex instance is able to reach the Jira instance. We route our requests through a static IP address. Reach out to support at to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your Jira instance.
Step 1: Create an application link from Jira
In your Jira server, navigate to Settings > Applications > Application Links. Click Create link.
Configure Jira with Cortex Axon Relay
See for instructions.
Configure the integration for multiple Jira accounts
The Jira integration has multi-account support. You can add a configuration for each additional by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the Jira page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
You can set a custom JQL query for your Jira integration instances and for individual entities. This allows you to filter which Jira work items are surfaced on entity pages or in other places in Cortex where CQL is used.
The default JQL applies to jira.issues() and jira.numOfIssues() but not to jira.rawJql().
Note that if you define additional filter logic for your default JQL query when writing a Scorecard rule, you must add that logic in a filter clause. See Adding filter logic to the default JQL query in a Scorecard for more information.
Set default JQL query at a tenant level
From the Jira settings page in Cortex, you can set a custom JQL query for your Jira integration.
When Cortex queries for Jira work items, the statusCategory is directly grabbed from the API response.
The default query — statusCategory in ("To Do", "In Progress") — will filter your Jira tickets to display only those with To Do and In Progress statuses, excluding closed tickets. The indeterminate status category will map to In Progress according to the API. Cortex does not use the status field for mapping these categories.
Entering a custom JQL query on the Jira integration settings page allows you to override the default for all entities in your workspace. To map work items with a custom status, you can write a custom JQL query that uses status instead of statusCategory.
Set default JQL query at entity level
You can configure default JQL for entities in their . For example:
It is possible to set custom JQL at both the entity and tenant level, but note the fallback logic:
If any JQL is passed into a query, Cortex uses that.
If not, Cortex uses entity-level default JQL.
If not, Cortex uses tenant-wide default JQL.
If none, then no JQL is used for filtering.
The CQL statement will use the default JQL setting in a Scorecard rule only if you do not define additional filter logic. Any filter logic applied to the statement will override the default JQL query.
To work around this: If you need to include additional filter logic on your query in a Scorecard, you can move the filter logic to the filter clause.
For example, if your default JQL query is set to "project = project_a", then you can add jira.issues() to a Scorecard rule to automatically surface only the work items relating to Project A. However, you cannot use jira.issues(some_other_filter_logic) in a Scorecard; Cortex will not append your default JQL to the additional filter logic.
In this example, the workaround would be to add a filter clause:
jira.issues().filter(some_other_filter_logic).
By default, Cortex will tie Jira tickets to entities by searching for any tickets where the label, component, or project field for the work item includes the Cortex tag. For example, if your Cortex tag is “my-entity,” then the corresponding tickets in Jira should have “my-entity” as a label, component, or project.
If your Jira label/component/project doesn't cleanly match the Cortex tag, you can override this in the Cortex entity descriptor.
Without an override, a ticket's label, component, or project must exactly match the Cortex tag in the descriptor.
Connect Jira entities via the Cortex UI
Navigate to an entity's details page in Cortex.
In the upper right corner, click Configure entity.\
Click the Project management tab, then click +Add.\
In the side panel, configure the details:
Jira service type: Choose component, label, or project.
Alias: If you have multiple Jira configurations, select which one this service is associated with.
Name: Enter the name of the service.
At the bottom of the side panel, click Add.
Editing the entity descriptor
If you need to override automatic discovery, you can define x-cortex-issues blocks in your Cortex entity descriptor.
Note: For all of the following, alias is optional, and the default Jira configuration will be used if not provided. You can use Jira labels, components, or projects to match entities.
Each of these blocks has the same field definitions.
Cortex maps Jira accounts to team members defined in the team catalog, so you do not need to define Jira users in a team member's YAML file.
You can confirm that users' Jira accounts are connected from the Jira user mappings section in Settings.
Once the integration is established, you'll be able to pull in data about the work items in any linked Jira instances for a given entity:
Number of issues: Unresolved issues associated with an entity that have the JQL status "in progress" or "to do"
Number of issues from JQL query: Issues associated with an entity that match an arbitrary JQL query
Cortex will tie Jira tickets directly to entities within the catalog. Click Issue tracking in the entity's sidebar to see associated Jira tickets.
From this tab you can find a list of all issues with a label that matches the Cortex tag.
Key: The issue key (or "ticket number") for a Jira work item.
Issue summary: Title of the Jira work item and the user designated as the issue reporter.
Assignee: User designated as the work item assignee.
Priority: The work item's priority level in Jira - Lowest, Low, Medium, High, Highest. This will display with the icon that corresponds to the priority level in your Jira instance.
Created: Date the work item was created.
Due: Due date for the work item, if applicable.
This list will also be available from a team's homepage when the team's Cortex tag matches a label, component, or project in Jira.
Initiatives allow you to set deadlines for specific rules or a set of rules in a given Scorecard and send notifications to users about upcoming due dates.
From the Issues tab of an Initiative, you can automatically create a Jira ticket from a failing rule.
Read about creating Jira issues from Initiatives in the documentation: Creating issues based on initiatives.
The Jira integration enables Cortex to pull information about issues into the dev homepage. You can find open work items assigned to you under the Issues tab. The work items that display will depend both on the Jira instances you've connected and the JQL query defined in Settings.
Work items are refreshed every 5 minutes. You can use the Refresh work items button to manually refresh issues at any point.
With the Jira integration, you can create Scorecard rules and write CQL queries based on Jira work items.
See more examples in the CQL Explorer in Cortex.
The engineering homepage runs a background job every 5 minutes to refresh the Issues tab.
I've added a Jira integration, but I'm not sure what JQL is being generated to query Jira.
When running Scorecard rules, Cortex appends AND (component = cortex-tag OR labels = cortex-tag OR project = cortex-tag) to the JQL you defined, where cortex-tag is the Cortex tag.
My Scorecard rules are failing, even though there are tickets in my Jira instance.
Make sure that the ticket has a label, component, or project that matches exactly with the Cortex tag or the list defined in your entity descriptor.
I received "Configuration error: Integration error for Jira: Unexpected HTTP response 0".
When using Jira Cloud, you'll need to create a Jira API token and add it on in Jira Settings in Cortex. The email address in Settings must be the same as the user that the token is associated with. Cortex also expects only the subdomain of your Jira instance, not the entire URL.
I received "Configuration error: Jira: Unexpected HTTP response 403: Forbidden".
Make sure that the entity name in Cortex matches the label, component, or project name in Jira.
Make sure the subdomain and base URL correspond with the Jira instance you're trying to connect.
Verify that the Jira token you added is still valid. You can run the following curl command to confirm:
I configured the integration, but I am not seeing Work Items populate.
The background job fetches work items every 5 minutes. However, a fresh integration configuration may result in longer waiting times, as it also fetches historical data.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
If you use the On-call Assistant, receive notifications when an incident is triggered
Interact with the Cortex Slack Bot to query entity metadata and Scorecard scores
Create Scorecards that enforce standards such as having Slack channels set for projects
To configure this integration:
Your Cortex user must have the Configure integrations permission
You must be an administrator in your Slack account
The Slack account must not be linked to another Cortex tenant
If you're using a self-managed Cortex instance, you'll need to follow a manual configuration process to use Cortex's app for Slack. Follow the self-managed Slack guide here.
In Cortex, navigate to the Slack settings page:
Click Integrations from the main nav. Search for and select Slack.
Click Add configuration.
In the side panel, click Add to Slack. A pop-up window will appear.
In the pop-up window that appears, sign in to your Slack workspace.
After signing in, a permission page will load in the pop-up window.
On the permission page, click Allow.\
After signing in to Slack and granting permission for Cortex to access the Slack workspace, you are redirected to the Slack integration settings page in Cortex. In the upper right corner of the page, click Test configuration to ensure Slack was configured properly.
On the Slack settings page, you can configure additional options:
Require Cortex account to use Cortex's Slack app: Enable this setting if you want Cortex's Slack app to only work for users who have Cortex accounts.
Slack notifications: You can configure notifications to be sent via Slack for your organization. Click Notification settings to go directly to the notification configuration page for your workspace.
Learn more about notifications below, under Managing Slack notifications.
Identity mappings: You can map email addresses from your Slack workspace to email addresses of team members in Cortex, making sure the integration works as expected for users. Click Identity mappings to go directly to the Identity mapping configuration page for your workspace.
.
Slack channels associated with teams or entities will appear in several places across Cortex:
Entity details page: Slack channels will appear at the top of an entity's overview page in a Slack channels block, and in the "Owners" page in the entity's sidebar. You can click any channel name to go directly to that channel in Slack.\
You can write CQL queries and Scorecard rules based on Slack channels. Learn more under Scorecards and CQL.
After configuring the Slack integration, you can choose whether to allow Slack notifications for your workspace.
In Cortex under Settings > Notifications, an admin or a user with the Configure workspace notification settings permission can enable or disable the option to receive notifications via Slack for each type of notification. Users can also adjust their personal notification settings to control which notifications they receive via Slack.
Notifications are user-based, team-based, or entity-based. DMs and channel notifications are sent from the Cortex Slack Bot.
User-based notifications are sent to users via a Slack DM.
Team-based notifications are sent to the Slack channel associated with a team.
Entity-based notifications are sent to the Slack channel associated with an entity.
Note that notifications can be sent to private Slack channels, but the Cortex Slack Bot must be a member of the channel in order for the notification to be delivered to the channel.
Learn more about notifications in the Notifications docs.
After configuring the Slack integration, you can use commands to interact with the Cortex Bot in your Slack workspace. The Cortex Bot also powers notifications that are sent via Slack.
The Cortex Bot is a Slack app called "Cortex."
The Cortex Bot sends you notifications based on which notifications are configured for your workspace (and based on your personal notification settings).
In addition, the Cortex bot will send user-based and team-based weekly reports. The weekly report for users summarizes how their entities are tracking against Scorecards and Initiatives; the report for teams delivers the same summary for entities owned by that team.
To ensure you receive notifications to a private channel, make sure you have added it to that channel:
Open the Slack channel where you want to add the bot.
Type and enter @Cortex.
Slack will prompt you to take an action. Click Add them.
Using the below commands in Slack, you can quickly query entity metadata and Scorecard scores. The <tag> refers to the Cortex tag.
Command
Result
/cortex dependencies <tag>
List all incoming and outgoing first-level dependencies
/cortex deploys <tag>
List recent deploys
/cortex docs <tag>
List all
/cortex domain <tag>
List domain information, such as owners, on-call, links, and timeline events
/cortex entity <tag>
List information for any entity, combining the behavior of service, team, domain and resource
/cortex help <tag>
Display the full list of commands
The Cortex AI assistant is a conversational interface that helps you navigate Cortex. You can ask the AI assistant questions such as "Which entities do I own?"
Use it with Slack in the following ways:
In a public channel: Tag Cortex (type @Cortex) and ask a question.
In a DM: Message the Cortex app directly and ask a question.
In order to use this integration's functionality, your Slack channels need to be associated with entities in Cortex. You can connect Slack channels to teams and other entities in an entity descriptor when following a GitOps approach, or you can connect them in the Cortex UI.
Without configuring the Slack integration, you can also add a Slack channel as an external documentation link on an entity.
Editing the entity descriptor
You can define Slack channels by name or ID, and enable or disable notifications to the channel, in an entity descriptor for any entity type. Defining a Slack channel will enable direct access to the channel from the entity's page in Cortex.
When to define by name vs. channel ID
When you define by name, it is more easily recognizable to users when viewing the entity's YAML. However, if a Slack channel's name is likely to change, it's better to define by ID as it won't break the entity's Slack link in Cortex.
Defining by channel IDs
We recommend registering Slack channels by ID, as channel names may change.
Defining by channel names
Connect channels to entities without configuring the Slack integration
You can connect Slack channels to entities without configuring the Slack integration. Note that this method will only provide a link to Slack from the entity; it will not include any features of the Slack integration, such as ownership tracking, notifications, Slack Bot, and the ability to use CQL to query Slack data.
Use format, https://slack.com/app_redirect?channel={channel_name}, to add the link to an entity YAML, under the x-cortex-slack block. Make sure to replace channel_name with your Slack channel's name.
Navigate to an in Cortex.
In the upper right corner, click Configure entity.\
Click the Slack channels tab, then click +Add.\
Cortex maps email addresses in your organization's Slack workspace to email addresses that belong to team members, so you never need to define email addresses in the entity descriptor.
You can confirm that users' Slack accounts are connected from the Onboarding management tool or from the identity mappings section in settings.
With the Slack integration, you can create Scorecard rules and write CQL queries based on Slack channels.
See more examples in the CQL Explorer in Cortex.
Cortex conducts a background sync of Slack identities every day at 10 a.m. UTC.
Yes, this is possible, depending on the settings you configured for the Slack Bot in your workspace. To allow users to use the Slack Bot without logging in to Cortex, navigate to the Slack integration settings page in Cortex and disable the toggle next to Require Cortex account to use Cortex's Slack app.
You can adjust your personal notification settings, but note that some types of notifications cannot be disabled.
No, the Slack integration is not required to add channels to Cortex teams. You can manually add any Slack channels without setting up the Slack integration via the entity descriptor or via the API for a team’s metadata.
Slack channels are cached and refreshed every 4 hours, so newly-added channels may not appear immediately in the UI.
Cortex retains basic Slack metadata like user IDs for the period necessary to fulfill the purposes outlined in our Privacy Policy unless a longer retention period is required or permitted by law, or where the Customer Agreement requires or permits specific retention or deletion periods.
To request to access, transfer, or delete data, you can reach out to the Cortex support team.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
jira.numOfIssues() <= 10jira.numOfIssues("status = \"Open\" and labels = \"customer-facing\"") <= 3curl -D- \
-X GET \
-H "Authorization: Basic {{your-token}}" \
-H "Content-Type: application/json" \
"https://{{your-domain}}.atlassian.net/rest/api/2/issue/{{valid-ticket-number}}"x-cortex-slack:
channels:
- id: ABCDEF123
notificationsEnabled: true
description: This is a description for this Slack channelslack != nullslack.channels().length > 0slack.numOfMembers() < 1In the side panel, configure the Slack channel details:
Channel name: Type in or select your Slack channel's name.
Description: Add a description to help others understand the purpose of the Slack channel.
Notifications: If enabled, you will receive notifications to this Slack channel.
At the bottom of the side panel, click Add.
/cortex links <tag>
List all links
/cortex links [type] <tag>
List all links of a type parameter, such as metrics or openapi
/cortex logs <tag>
List all logs links
/cortex oncall <tag>
Find current on-call info
/cortex owners <tag>
List all owners and their email addresses
/cortex resource <tag>
List resource information, such as owners, on-call, links, and timeline events
/cortex runbooks <tag>
List all runbook links
/cortex scores <tag>
List all Scorecard scores
/cortex search <tag>
Query for entities using Lucene queries.
For example:
- Search by tag with key:value
- Use wildcards: foo*, foo:bar*
- Search by group with group:name
/cortex sentry <tag>
List recent Sentry issues
/cortex service <tag>
List service information, such as owners, on-call, links, and timeline events
/cortex team <tag>
List team information, such as owned entities, links, and timeline events
/cortex timeline <tag>
List recent timeline events
id
Slack channel ID
✓
notificationsEnabled
Boolean to enable/disable notifications in Slack
✓
description
Description for the Slack channel
name
Slack channel name
✓
notificationsEnabled
Boolean to enable/disable notifications in Slack
✓
description
Description for the Slack channel







x-cortex-slack:
channels:
- name: team-engineering
notificationsEnabled: true
description: A description for this Slack channel.x-cortex-slack:
channels:
- name: https://slack.com/app_redirect?channel=channel_namePassword: Enter the app password you created in the previous steps.
You can find this in Bitbucket under Personal settings > Account settings > Bitbucket profile settings.
Password: Enter the app password you created in the previous steps.
Client secret: Enter the client secret you obtained in the previous steps.






group:jiraIn the Jira integration modal, "Jira Cloud" is selected by default in the upper right corner. Configure the integration form:
Account alias: Enter an alias for your account.
Subdomain: Enter the subdomain for your Jira instance.
For example, this field would take cortex-docs from https://cortex-docs.atlassian.net.
Base URL: This field automatically populates atlassian.net.
If you are using a legacy Jira Cloud instance (i.e., you access your Jira instance on jira.com), change the base URL from the dropdown.
Email: Enter the email address associated with the user who generated the token in Jira.
Note: The email address associated with a given Jira token must match the email address of the user associated with that token.
API token: Enter your Jira API token.
Click Save.
Under "Integrations," click Jira.
Click Add configuration.
In the upper right corner of the Jira integration modal, click the dropdown labeled Cloud. Select On-prem (basic auth).
Configure the Jira integration form:
Account alias: Enter an alias for your account.
Host: Enter the URL for your Jira on-premises host.
Frontend host: Enter the URL for your Jira on-premises frontend host.
Username and Password: Enter your Jira username and password.
Click Save.
Configure the application link settings:
Application type: Select External.
Direction: Select Incoming.
Redirect URL: For default configuration, enter the URL of your Cortex instance appended with /oauth/internal/jira. For a non-default configuration, enter the URL of your Cortex instance appended with /oauth/internal/jira/.
Permission: Select write.
Click Save.
The application link will have an associated client ID and client secret. Copy these values and store them in a secure location, as you will need them in the next steps.
Step 2: Configure the integration in Cortex
In Cortex, navigate to the Jira settings page:
In Cortex, click your avatar in the lower left corner, then click Settings.
Under "Integrations," click Jira.
Click Add configuration.
In the upper right corner of the Jira integration modal, click the dropdown labeled Cloud. Select On-prem (OAuth).
Configure the Jira integration form:
Account alias: Enter an alias for your account.
Host: Enter the URL for your Jira on-premises host.
Frontend host: Enter the URL for your Jira on-premises frontend host.
Click Save.
You will be redirected to the Jira settings page. Click Install next to your integration name.
A confirmation modal will appear, asking you to allow Cortex access to your Jira account.
The accessing user can be a user persona or a system account. We recommend using a system account to maintain your organization's access in case the user who set up the integration leaves your organization.
name
Label name in Jira
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
By default, Cortex will surface outstanding issues per entity in the catalog with a default JQL query: statusCategory in ("To Do", "In Progress"). If you'd like to override this, you can provide a new default query with:


GitLab is a Git-based version control system with cloud and self-hosted options.
Integrating GitLab with Cortex allows you to:
Discover and track ownership of entities
Follow a GitOps workflow with GitLab
View commits alongside events and other data on entity pages in Cortex
View information about merge requests in the
Use GitLab metrics in to understand key metrics and gain insight into services, incident response, and more
Create to monitor development maturity relating to GitLab projects
There are two options for integrating GitLab: the default configuration method and Cortex Axon Relay, a relay broker allows you to securely connect your on-premises GitLab data.
Before getting started:
A GitLab user with at least the Maintainer role must create a GitLab or with the read_api scope.
We recommend that you create the token at the parent group level, as GitLab does not support using a scoped token to read members from a parent group. If you do not create the token at the parent level, then you will need to manually configure groups in your GitLab settings in order for identity mapping and teams to work as expected.
If you're using the Scaffolder for entities in a given GitLab instance, make sure that configuration has the full
If you're using a self-hosted instance of GitLab, you'll need to verify that your Cortex instance is able to reach the GitLab instance. We route our requests through a static IP address. Reach out to support at to receive details about our static IP. If you're unable to directly allowlist our static IP, you can route requests through a secondary proxy in your network that has this IP allowlisted and have that proxy route traffic to your GitLab instance.
Configure the integration in Cortex
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select GitLab.
Click Add configuration.
Once you save your configuration, you'll see it listed on the integration's settings page in Cortex. If you’ve set everything up correctly, you’ll see the option to Remove Integration in Settings.
You can also use the Test all configurations button to confirm that the configuration was successful. If your configuration is valid, you’ll see a banner that says “Configuration is valid. If you see issues, please see documentation or reach out to Cortex support.”
Configure the integration for multiple GitLab accounts
The GitLab integration has multi-account support. You can add a configuration for each additional by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the GitLab page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
Cortex supports mapping multiple identities for a single user if you have multiple configurations of GitLab. See the for more information.
Cortex supports a GitOps approach, which allows you to manage entities in Cortex through your version control system. If you would prefer this workflow over the UI for the GitLab integration, you must create a webhook. Please see the for instructions.
Cortex will discover entities for import from your GitLab configuration(s). These will appear in the import entities workflow.
See the for instructions on importing entities manually.
Git
By specifying the x-cortex-git field in your Cortex entity descriptor, you'll be able to see Git information in the entity page, including the top language, recent commits, and top contributors.
Only one repository can be defined for in a given entity's YAML in the x-cortex-git block.
Ownership
You can define the following block in your Cortex entity descriptor to add your GitLab groups.
Team name should match the group name in GitLab.
Cortex maps users' email addresses to discovered GitLab accounts, so you never need to define email ownership in an entity descriptor.
You can confirm users' GitLab accounts are connected from .
If users are not loading in the identity mapping page, make sure that you have created your GitLab personal access token from the parent level as described in the .
Cortex uses the GitLab integration for a significant amount of data that appears on .
The GitLab integration will populate the Repo and Language detail blocks on an entity's details page.
In the Recent activity preview, you'll find the recent commits and releases. These will also appear in the event timeline.
These data will appear for entities imported from a Git source or those that have a Git repo defined in their YAMLs.
On an entity's Events page, you can find all of the commits and releases associated with that entity. Each is hyperlinked to the commit or release page in GitLab and includes a timestamp.
You can access more detailed information pulled from GitLab in the Repository page in the entity's sidebar. At the top of the page, you'll find the repo associated with that entity and the most-used language in files for that entity. In the Top contributors block, you'll find the three users who have contributed the most code and the number of their contributions.
In the Commits section, you'll find the 10 most recent commits and metadata about each. Below Commits is the Recent releases section, which includes the 5 most recent releases.
When a GitLab team is registered in a team entity descriptor, Cortex will pull GitLab users in to the Members tab. When available, Cortex will pull in the profile picture and email address for each user.
If team members are not appearing as expected, make sure that you have created your GitLab personal access token from the parent level as described in the .
The GitLab integration enables Cortex to pull information about merge requests into the . You can find your open merge requests and any merge requests assigned to you for review.
Merge requests from GitLab are refreshed every 2 minutes.
The also uses merge request data from GitLab to generate metrics:
Average MR open to close time
Avg time to first review
Avg time to approval
MRs opened
You can read more about how Eng Intelligence tracks metrics for teams and users in the Eng Intelligence walkthrough.
To add deployments for your GitLab related entity, you can send a deployment event to the .
With the GitLab integration, you can create Scorecard rules and write CQL queries based on GitLab data.
See more examples in the in Cortex.
Ownership CQL
Cortex conducts a background sync of GitLab identities every day at 10 a.m. UTC. Merge requests are refreshed every 2 minutes.
Why is my CQL query git.branchProtection() returning no results or a 403 error?
This can happen if you do not have the read_api scope set for your access token, or if the GitLab user who generated the token does not have at minimum the Maintainer role.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
x-cortex-issues:
jira:
projects:
- name: PROJECT_A
alias: Jira Project A
defaultJql: "project = project_a"x-cortex-issues:
jira:
labels:
- name: labelA
alias: alias1
- name: labelBx-cortex-issues:
jira:
components:
- name: component1
alias: alias1x-cortex-issues:
jira:
projects:
- name: project1
alias: alias1x-cortex-issues:
jira:
labels:
- name: label1
- name: label2
- name: label3
components:
- name: component1
- name: component2x-cortex-issues:
jira:
defaultJql: 'status = "In Progress"'Client ID and Client secret: Enter the client ID and secret associated with the application link you created in the previous steps.
apiConfigure the GitLab integration form:
Account alias: Enter the alias you will use to tie entity registrations to different configuration accounts.
Token: Enter your personal or group access token.
Host: Enter your host. If using a custom GitLab instance, enter the URL without the API path (e.g. https://gitlab.getcortexapp.com)
Hide personal projects: Toggle this setting on if you do not want your personal projects pulled in to Cortex. Toggle this setting off to allow Cortex to pull your personal projects.
Click Save.
Configure GitLab with Cortex Axon Relay
See Internally hosted integrations for instructions. Make sure to follow the GitLab-specific instructions for the docker-compose.yml file.
Avg MRs reviewed/week
Avg commits per MR
Avg lines of code changed per MR
Definition: git.branches()
Example
For a best practices Scorecard, you can make sure that branches associated with an entity match a standard naming convention:
Required status checks
Restrictions apply to admin
Review required
Definition: git.branchProtection()
Examples
For a security Scorecard, you can write a rule to make sure the default branch is protected:
Because vulnerabilities in the default branch are critical, this rule should be in one of the first couple levels.
You can also use the Query Builder to find entities with unprotected default branches:
SHA
URL
Username
These results can be filtered based on branch name, using the default branch if no other branch is provided.
Definition: git.commits()
Example
You can use the git.commits() expression in a security Scorecard to make sure entities have fewer than three commits to a "security-fixes" branch in the last week:
Entities passing this rule will include those that haven't needed three or more security fixes. This can indicate that there aren't vulnerabilities in a given entity's code, but could also suggest that fixes aren't being implemented. Using this rule in conjunction with one focused on vulnerabilities could provide the extra context needed to gain a better understanding of what's happening.
To make sure node engine version in specified in the package.json file:
To make sure TypeScript projects have a tsconfig.json file checked in:
To make sure projects using yarn do not allow NPM:
And to ensure the yarn version being used is not deprecated:
URL
Username
Definition: git.lastCommit()
Examples
One of the first rules you might write for a Scorecard focused on development maturity or security is one validating that the last commit was within the last month:
As counterintuitive as it may seem, services that are committed too infrequently are actually at more risk. People who are familiar with the service may leave a team, institutional knowledge accumulates, and from a technical standpoint, the service may be running outdated versions of your platform tooling.
Depending on best practices at your organization, you may want to confirm entities are updated within a week:
Confirming whether a service was updated within the last week can help team members catch outdated code sooner. Plus, if there is a security issue, you can quickly determine which services have or have not been updated to patch the vulnerability.
Date opened
First review date
Last updated
Number of commits
Number of lines added
Number of lines deleted
Organization
Repository
Source
Status
URL
Definition: git.pullRequests()
Example
You can use the git.pullRequests() query to find entities that have a small number of pull requests opened in the last two weeks:
This can highlight entities that haven't been updated recently, which may be especially useful when entities have to be updated to address a vulnerability.
Reviewer
Definition: git.reviews()
Examples
A development maturity Scorecard might use the git.reviews() expression to make sure that there is a rigorous review process in place before changes are implemented:
This rule makes sure that there are more than 25 reviews left in the last week.
Run time
Run updated at
Status
Conclusions: FAILURE, SUCCESS, TIMED_OUT
Statuses: QUEUED, IN_PROGRESS, COMPLETED
The lookback period specifies a duration for which returned runs should be created within, defaulting to a period of 3 days.
The runTime of the WorkflowRun object represents the difference between runStartedAt and runUpdatedAt times in seconds.
Definition: git.workflowRuns()
Example
To make sure an entity has had a successful workflow run within the last two weeks, you can write a rule like:
This rule is checking for GitHub workflow runs with a SUCCESS conclusion and COMPLETED status during a 14-day lookback window.
repository
GitLab project ID or namespace/repo as defined in GitLab
✓
basepath
Subdirectory for the entity if it is in a monorepo
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
type
Ownership type; must be defined as group for GitLab teams
✓
name
GitLab team name
✓
provider
Name of integration (in this case, GITLAB)
✓
description
Description for the GitLab team
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
Packages are automatically scraped from your Git repos or they can be submitted via the packages API. The package file must be in the root of your repository — or, if you're using basepath, in the root of the subdirectory — to be scraped by Cortex. You can query an entity's packages in CQL explorer using packages().
To view packages, click Packages in the entity's sidebar.
The following package types are automatically scraped from repositories:
JavaScript / Node.js: package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
Python: requirements.txt, pipfile.lock
.NET (C#): packages.lock.json
Java: pom.xml
Go: go.sum
All other files of these types can be added via the .
Packages are automatically scraped from your Git repos or they can be submitted via the packages API. The package file must be in the root of your repository — or, if you're using basepath, in the root of the subdirectory — to be scraped by Cortex. You can query an entity's packages in CQL explorer using packages().
To view packages, click Packages in the entity's sidebar.
The following package types are automatically scraped from repositories:
JavaScript / Node.js: package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
Python: requirements.txt, pipfile.lock
.NET (C#): packages.lock.json
Java: pom.xml
Go: go.sum
All other files of these types can be added via the .
Getting deployment data into Cortex is critically important for both engineering insights and organizational success. It enables the use of to assess and other KPIs to understand how quickly and efficiently your teams are shipping code. Deployment data also gives you the insight needed to create and that promote process improvement across teams.
When you add deploy data to Cortex, it is visible on , in Eng Intelligence and the and , in , and can be accessed via .
To get deploys into Cortex, you must use the API endpoint.
jq(git.fileContents("package.json"), ".engines.node") != nulljq(git.fileContents("package.json"), ".devDependencies | with_entries(select(.key == \"typescript\")) | length") == 0 or git.fileExists("tsconfig.json")jq(git.fileContents("package.json"), ".engines.yarn") == null or jq(git.fileContents("package.json"), ".engine.npm") = "please-use-yarn"x-cortex-git:
gitlab:
repository: cortex/docs
basepath: myService
alias: myAppx-cortex-owners:
- type: group
name: Team Name
provider: GITLAB
description: This is a description for this ownergit.numOfRequiredApprovals() > 0git.numOfRequiredApprovals() < 1git != nullgit.percentBuildSuccess() > 0.9git.defaultBranch().matches("main")git.fileContents("circleci/config.yml").matches(".*npm test.*")git.fileExists("README.md")git.fileExists("yarn.lock") OR git.fileExists("package-lock.json")git.fileExists("*Test.java")git.numOfVulnerabilities() == 0git.numOfVulnerabilities(severity=["CRITICAL"]) == 0git.numOfVulnerabilities(severity=["WARNING"]) == 0git.vulnerabilities().length < 5git.vulnerabilities(severity=["CRITICAL"]).length == 0git.hasCortexYaml() == trueownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)ownership.teams().all(team => team.description != null and team.isArchived == false)git.branches().all((branch) => branch.name.matches("(main|master|feat-.*|bug-.*|task-.*)"))git.branchProtection() != nullgit.branchProtection() = nullgit.commits(branch="security-fixes", lookback=duration("P7D")).length < 3git.fileExists(".prettierrc.json") OR git.fileExists(".eslintrc.js")git.lastCommit().freshness < duration("P1M")git.lastCommit().freshness < duration("P7D")git.pullRequests(lookback=duration("P14D")).length < 3git.reviews(lookback=duration("P7D")).length > 25git.workflowRuns(conclusions=["SUCCESS"], statuses=["COMPLETED"], lookback=duration("P14D")).length > 0jq(git.fileContents("package.json"), ".engines.yarn") == null or !(semver("1.2.0") ~= semverRange(jq(git.fileContents("package.json"), ".engines.yarn")))In these examples, the repository secret or variable contains a valid Cortex API key, and the repository name matches the Cortex tag.
Adding a customData object to your API call allows you the flexibility to add metadata that is important to your organization.
If custom data is included for a deploy, you can view it under "CI/CD > Deploys" on an entity's details page. Click the "Details" drop-down to expand and view the custom data:
Deployment information appears in several places on an entity page:
While viewing an entity page, you can see last deployment information near the top of the page:\
Near the bottom of an entity page, deploys will also appear under "Recent activity."
In the left sidebar of an entity, click Events. This page includes:
A visual chart of deploys.
By default the chart shows data from the last month. Click the Last month dropdown in the upper right to change the timeframe.
All recent events for the entity. In the upper right corner of the events list, click Filter to select and apply filters for this list. You can choose to only view the deploy event types. \
When you send deploy data into Cortex, you can use this information in Eng Intelligence reporting to gain insight into your deploy metrics. Deploy metrics include average number of deploys per week and deploy change failure rate.
In Eng Intelligence, click into an entity to open a side panel with a historical performance graph.
Read more about using Eng Intelligence in the documentation.
You can use deploy data to write rules for Scorecards and to create CQL reports.
See more examples in the CQL Explorer in Cortex.
is a Microsoft-owned version control system used for managing the software development lifecycle.
Integrating Cortex with Azure DevOps allows you to:
Automatically discover and track ownership of Azure DevOps entities
Follow a GitOps workflow with Azure DevOps
View information about your Azure DevOps repositories on an entity's details page, including: The repo associated with the entity, recent commits and releases in the event timeline, the most-used language in the files for that entity, the top code contributors, and their number of contributions
pipeline {
agent any
environment {
CORTEX_API_URL = "https://api.getcortexapp.com/api/v1/catalog"
}
stages {
stage('Build') {
steps {
script {
echo "Building application..."
}
sh '''
node --version
npm --version
npm ci
npm run build
'''
}
post {
success {
script {
env.BUILD_STAGE_RESULT = 'SUCCESS'
}
}
failure {
script {
env.BUILD_STAGE_RESULT = 'FAILURE'
}
}
}
}
stage('Test') {
steps {
script {
echo "Running tests..."
}
sh 'npm test'
}
post {
success {
script {
env.TEST_STAGE_RESULT = 'SUCCESS'
}
}
failure {
script {
env.TEST_STAGE_RESULT = 'FAILURE'
}
}
}
}
stage('Deploy') {
steps {
script {
echo "Deploying to staging..."
sh '''
sleep 2
echo "Deployment completed"
'''
}
}
post {
success {
script {
env.DEPLOY_STAGE_RESULT = 'SUCCESS'
}
}
failure {
script {
env.DEPLOY_STAGE_RESULT = 'FAILURE'
}
}
}
}
}
post {
always {
script {
notifyCortex()
}
}
}
}
def notifyCortex() {
try {
echo "Build Stage Result: ${env.BUILD_STAGE_RESULT ?: 'SKIPPED'}"
echo "Test Stage Result: ${env.TEST_STAGE_RESULT ?: 'SKIPPED'}"
echo "Deploy Stage Result: ${env.DEPLOY_STAGE_RESULT ?: 'SKIPPED'}"
// Determine overall pipeline status
def buildResult = env.BUILD_STAGE_RESULT ?: 'SKIPPED'
def testResult = env.TEST_STAGE_RESULT ?: 'SKIPPED'
def deployResult = env.DEPLOY_STAGE_RESULT ?: 'SKIPPED'
def pipelineStatus
def deployType
def message
if (buildResult == 'SUCCESS' && testResult == 'SUCCESS' && deployResult == 'SUCCESS') {
pipelineStatus = 'success'
deployType = 'DEPLOY'
message = 'Pipeline completed successfully'
} else {
pipelineStatus = 'failed'
deployType = 'ROLLBACK'
message = "Pipeline failed - one or more stages failed (Build: ${buildResult}, Test: ${testResult}, Deploy: ${deployResult})"
}
echo "Pipeline Status: ${pipelineStatus}"
echo "Deploy Type: ${deployType}"
echo "Message: ${message}"
// Convert repo name to lowercase (extract from job name)
def repoName = env.JOB_NAME.tokenize('/')[0].toLowerCase()
echo "Repository: ${repoName}"
// Get Git commit SHA and branch
def gitCommit = sh(
script: 'git rev-parse HEAD',
returnStdout: true
).trim()
def gitBranch = sh(
script: 'git rev-parse --abbrev-ref HEAD',
returnStdout: true
).trim()
// Get current timestamp
def timestamp = sh(
script: 'date -u +"%Y-%m-%dT%H:%M:%SZ"',
returnStdout: true
).trim()
// Escape JSON special characters in message
def escapedMessage = message.replaceAll('"', '\\\\"').replaceAll("'", "\\\\'")
// Get deployer information
def deployerEmail = env.BUILD_USER_EMAIL ?: '[email protected]'
def deployerName = env.BUILD_USER ?: 'Jenkins'
// Build JSON payload
def jsonPayload = """
{
"customData": {
"pipeline": "${env.JOB_NAME}",
"build_number": "${env.BUILD_NUMBER}",
"branch": "${gitBranch}",
"pipeline_status": "${pipelineStatus}",
"message": "${escapedMessage}",
"build_url": "${env.BUILD_URL}",
"jenkins_url": "${env.JENKINS_URL}"
},
"deployer": {
"email": "${deployerEmail}",
"name": "${deployerName}"
},
"environment": "staging",
"sha": "${gitCommit}",
"timestamp": "${timestamp}",
"title": "Pipeline ${pipelineStatus} - ${env.JOB_NAME}",
"type": "${deployType}",
"url": "${env.BUILD_URL}"
}
"""
// Send notification to Cortex
withCredentials([string(credentialsId: 'CORTEX_TOKEN', variable: 'CORTEX_TOKEN')]) {
def curlResult = sh(
script: """
curl -L \\
--request POST \\
--max-time 30 \\
--retry 2 \\
--url "${env.CORTEX_API_URL}/${repoName}/deploys" \\
--header "Authorization: Bearer \${CORTEX_TOKEN}" \\
--header "Content-Type: application/json" \\
--data '${jsonPayload}' \\
--write-out "%{http_code}" \\
--silent \\
--output /dev/null
""",
returnStdout: true
).trim()
if (curlResult == '200' || curlResult == '201') {
echo "Successfully notified Cortex (HTTP ${curlResult})"
} else {
echo "Failed to notify Cortex (HTTP ${curlResult}), but continuing..."
}
}
} catch (Exception e) {
echo "Failed to send Cortex notification: ${e.getMessage()}"
// Don't fail the build if notification fails
}
}deploys(lookback = duration("P1M"), types = ["DEPLOY"]).filter((deploy) => deploy.customData != null AND deploy.customData.get("bugFix") == true).length = 2deploys(lookback=duration("P1M"),types=["ROLLBACK"]).length / deploys(lookback=duration("P1M"),types=["DEPLOY", "ROLLBACK", "RESTART"]).length < 0.25


If you pull in Azure DevOps pipeline data, you can also see pipeline runs and builds in the CI/CD section of an entity's details page.
If you enable the option to pull in Azure DevOps work items, you will also see a list of open work items on entity pages.
View information about pull requests and work items in the engineering homepage
Use Azure DevOps metrics in Eng Intelligence to understand key metrics and gain insight into services, incident response, and more
Create Scorecards that track progress and drive alignment on projects involving your repositories, Azure DevOps work items, and Azure DevOps pipeline data
You can configure Azure DevOps with a Personal Access Token (PAT) or with a Service Principal with Entra ID.
Prerequisite
Before you get started:
Add a Azure DevOps personal access token with at least the following scopes enabled:
Analytics: read
Build: read
Code: read
If using the with Azure DevOps, you must also enable:
Code: write
Graph & Identity: read
Work Items: read and write
Configure the Azure DevOps integration with a PAT
In Cortex, navigate to the .
Click Integrations from the main nav. Search for and select Azure DevOps.
Click Add configuration and select Personal Access Token.
Prerequisite
Before you get started:
In your Azure portal under Entra ID > App registrations, .
You will need the Client ID and Azure Tenant ID associated with this app registration.
When you create an app registration, a Service Principal user is also generated.
Cortex supports mapping multiple identities for a single user if you have multiple configurations of Azure DevOps. See the Identity mapping documentation for more information.
On the Azure DevOps settings page in Cortex, you can choose whether Azure DevOps work items should be pulled in from Azure DevOps. Cortex recommends disabling this option if your organization does not use work items or if you are worried about running into rate limit issues.
See the Create services documentation for instructions on importing entities.
In an entity's YAML, you can define a repository, work items, ownership, and pipelines.
To define an Azure DevOps repository for a given entity, add the x-cortex-git block to the entity's descriptor.
project
The name of the project as listed under the "Projects" tab when you are logged into Azure DevOps (on the https://dev.azure.com// screen)
✓
repository
The repo name you see when you navigate to the "Repos" section of Azure DevOps
✓
basepath
If the entity is in a monorepo (e.g. in a subdirectory), use this field to define the subdir
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
Only one repository can be defined for in a given entity's YAML in the x-cortex-git block.
Before adding work items to your entity YAML, make sure you have enabled the option to pull in Azure DevOps work items in your integration settings.
To define Azure DevOps work items for a given entity, add the x-cortex-azure-devops block to the entity's descriptor. If there is no work item registrations, but the entity matches a repository, we will pull in all work items from the repository's project with a tag that matches the Cortex entity name, Cortex tag, or the repository name.
projects
List of the projects
✓
name
The project name as listed under the "Projects" tab when you are logged into Azure DevOps (on the https://dev.azure.com// screen)
✓
wiqls
List of WIQL conditions to filter work items fetched
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
Ownership of each entity through Azure DevOps is defined through an owner of type group.
name is a case-sensitive field that corresponds to the upstream identifier of your owner from Azure DevOps.
Learn more about ownership in Defining ownership.
You can add Azure DevOps pipelines under the x-cortex-azure-devops block:
piepelines
List of the pipelines
✓
projects
List of the projects
✓
name
The project name as listed under the "Projects" tab when you are logged into Azure DevOps (on the https://dev.azure.com// screen)
✓
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
Learn more about Azure DevOps pipelines in Microsoft's documentation.
Cortex maps users' email addresses to discovered Azure DevOps accounts.
You can confirm users' Azure DevOps accounts are connected from Azure DevOps identity mappings in settings.
Initiatives allow you to set deadlines for specific rules or a set of rules in a given Scorecard and send notifications to users about upcoming due dates.
From the Issues tab of an Initiative, you can automatically create a Azure DevOps work item from a failing rule:
Click Create issue.
In the modal that appears, fill out the form:
Integration: If you have multiple task tracking tools, select Azure DevOps from the Integration dropdown.
Name: Enter a name for the configuration.
Project: Select from the dropdown.
Options available in the dropdown are pulled in from the specific Azure DevOps instances configured in Settings.
Select the and the Sub-item Type from the respective dropdowns. Then, select how the sub-items's fields should be populated on issue creation and status change.
Choose to include or exclude groups of entities, or define a more advanced filter.
The issue configuration will apply to all entities that meet the filter criteria. Once an entity is passing the rule, Cortex will automatically close the associated ticket.
The Azure DevOps integration will populate the Repo detail block on an entity's details page.
In the Recent activity preview, you'll find the recent commits and releases. These will also appear in the event timeline.
These data will appear for entities imported from a Git source or those that have a Git repo defined in their YAMLs.
On an entity's Events page, you can find all of the commits and releases associated with that entity. Each is hyperlinked to the commit or release page in Azure DevOps and includes a timestamp.
From the CI/CD > Azure DevOps page in the entity's sidebar, see a history of pipeline runs.
You can access more detailed information pulled from Azure DevOps under Repository in the sidebar. At the top of the repository page, you'll find the repo associated with that entity and the most-used language in files for that entity. In the Top contributors block, you'll find the three users who have contributed the most code and the number of their contributions.
In the Commits section, you'll find the 10 most recent commits and metadata about each. Below Commits is the Recent releases section, which includes the 5 most recent releases.
In the Issue tracking section, you can find a list of open Azure DevOps work items. Each work item will show the title, summary, assignees, priority, and date created.
The Azure DevOps integration enables Cortex to pull information about pull requests and work items into the homepage. You can find your open pull requests, any pull requests assigned to you for review, and any work items assigned to you.
Pull requests and work items from Azure DevOps are refreshed every 5 minutes.
The Eng Intelligence tool also uses pull request data from Azure DevOps to generate metrics:
Average PR open to close time
Avg time to first review
Avg time to approval
PRs opened
Weekly PRs merged
Avg PRs reviewed/week
Avg commits per PR
Read more about how Eng Intelligence tracks metrics for teams and users in the Eng Intelligence documentation.
With the Azure DevOps integration, you can create Scorecard rules and write CQL queries based on Azure DevOps work items.
See more examples in the CQL Explorer in Cortex.
Cortex conducts a background sync of Azure DevOps identities every day at 10 a.m. UTC. Pull requests and work items are refreshed every 5 minutes.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Packages are automatically scraped from your Git repos or they can be submitted via the . The package file must be in the root of your repository — or, if you're using basepath, in the root of the subdirectory — to be scraped by Cortex. You can query an entity's packages in using packages().
To view packages, click Packages in the entity's sidebar.
The following package types are automatically scraped from repositories:
JavaScript / Node.js: package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
Whether you use the to , every entity in your Cortex catalogs is defined by a YAML file called the Cortex entity descriptor, also referred to as an entity's Cortex YAML (stemming from cortex.yaml, the name of the file that powers the .)
Each file is a fully compliant OpenAPI 3 spec file, with our own Cortex-specific extensions.
SELECT
[System.Id],
[System.AssignedTo],
[System.State],
[System.Title],
[System.Tags]
FROM workitems
WHERE
'[System.TeamProject] = Design Agile'
AND '[System.WorkItemType] = User Story'
AND '[System.State] = Active'
ORDER BY [System.ChangedDate] DESC
ASOF '02-11-2020'git.numOfRequiredApprovals() >= 1git.numOfRequiredApprovals() < 1git.branchProtection() != nullgit.branchProtection("main") != nullgit.branchProtection("main").requiredStatusChecks.length > 0git.commits(branch="security-fixes").length < 3git.defaultBranch().matches("main")git.fileExists(“package-lock.json”)git.fileExists(*Test.java”)git.fileExists("terraform/versions.tf") and !git.fileContents("terraform/versions.tf").matchesIn("required_version =! \"[~>= ]{0,3}0\\.(12|13)")git.hasCortexYaml() == truegit != nulldatetime(git.lastCommit().date).fromNow() > duration("P-3D")git.lastCommit().message.matches("^(feat|fix|docs|style|refactor|test|chore)(\\(.+\\))?:*")azureDevops.pipelines().any(pipeline => pipeline.name.matchesIn("Vuln scan"))azureDevops.pipelines() != nullgit.percentBuildSuccess() >= 0.95azureDevops.pipelineMetrics().all((pipeline) => pipeline.metrics.successRate > 0.95)azureDevops.pipelineRuns().filter(run => run.run.completedDate != null).map((run) => run.run.createdDate.until(run.run.completedDate)).averageDuration() < duration("P1D")git.lastCommit().freshness < duration("P1M")git.codeSearch(query = "icon", fileExtension = "css").length > 0git.topLanguage() == "kotlin"git.topLanguage() != "kotlin"azureDevops.workItems().length <= 10jira.workItems("System.State = \"Doing\" AND Microsoft.VSTS.Common.Priority = 1").length <= 3x-cortex-git:
azure:
project: cortex
repository: docs
basepath: myService
alias: accountAliasx-cortex-azure-devops:
workItems:
projects:
- name: projectName1
wiqls:
- "[System.TeamProject] = 'Design Agile'"
- "[System.WorkItemType] = 'User Story'"
- "[System.State] = 'Active'"
- ORDER BY [System.ChangedDate] DESC ASOF '02-11-2020'
- name: projectName2
alias: alias1
- name: projectName3
alias: alias2x-cortex-owners:
- type: group
name: My Azure DevOps Team
provider: AZURE_DEVOPS
description: This is a description for this owner # optional x-cortex-azure-devops:
pipelines:
projects:
- name: projectName1
alias: config-1
pipelines:
- id: 1
- name: projectName2
alias: config-2
pipelines:
- id: 2manageOrganization: Enter the slug for your Azure DevOps organization.
Username: Enter the username for your personal access token.
Personal access token: Enter your Azure DevOps personal access token.
Host: Optionally, if you are using a self-managed setup, enter your hostname.
Click Save.
In your Azure portal, create a Client Secret for your app registration.
While viewing the overview of your app registration, click the link next to "Client credentials." You will be directed to the Certificates & secrets page, where you can click +New client secret to create a secret.
Step 1: Add your Service Principal to your Azure DevOps organization
You must add the Service Principal user to the organization you're integrating with Cortex.
In Azure DevOps, from the list of organizations, select the one you will be integrating with Cortex.
Navigate to Organization Settings > General > Microsoft Entra. Connect your Entra ID directory (the one containing the app registration) with the Azure DevOps organization.
Navigate to Organization Settings > General > Users, then click Add users.
In the side panel, configure the new user:
Users or Service Principals: Enter the Service Principal associated with your app registration.
Access level: Select Basic.
Add to projects: Add the user to the project(s) that your Cortex integration will need access to.
At the bottom of the side panel, click Add.
Step 2: Configure the Azure DevOps integration in Cortex
In Cortex, navigate to the Azure DevOps settings page.
Click Integrations from the main nav. Search for and select Azure DevOps.
Click Add configuration and select Service Principal.
Configure the Azure DevOps integration form:
Category: Select which integration categories this configuration will apply to.
Configuration alias: Enter an alias for this configuration.
Organization: Enter the slug for your Azure DevOps organization.
Client ID: Enter the Application Client ID for your app registration.
Click Save.
Python: requirements.txt, pipfile.lock
.NET (C#): packages.lock.json
Java: pom.xml
Go: go.sum
All other files of these types can be added via the packages API.
pipelines:id
The Azure DevOps system.definitionID for the pipeline.
✓
The metadata you add to your descriptor belongs in the info section of the YAML file.
Throughout the Cortex docs, you'll see metadata examples that start with x-cortex-* – these belong in the info section of your entity YAMLs.
Note that it is not currently supported to include comments in YAML files.
Every entity YAML requires the following:
title: The entity's name
x-cortex-tag: The unique identifier for the entity
x-cortex-type: The entity type
If the entity is a , you must also include x-cortex-definition.
Although they aren't required, we recommend adding a description, groups, and owners:
description: A description of the entity
x-cortex-groups: The entity's groups - a tagging system used to segment entities
Required field: tag
x-cortex-owners: The entity's
Required field: type
Owners can be defined by group from an or by email address.
inheritance
x-cortex-custom-metadata: The entity's custom data
Required fields: a key, value, and description. The key is the title for the custom data.
x-cortex-dependency: The entity's dependencies
Required fields: tag. If method is included, then path is also required.
x-cortex-link: associated with the entity
name, type, and url
x-cortex-parents and x-cortex-children: The entity's parent entities and children entities.
Required field: tag
These fields are supported for entities that are members of a , such as domains or teams.
x-cortex-relationships: A block that includes the entity's .
Required fields: type and destinations
x-cortex-team: This appears in a . Under this block you can define members.
A member is defined by name and email, and can also include notificationsEnabled and roles.
See the related linked documentation pages for instructions on adding metadata within each type of block.
x-cortex-alerts: Opsgenie
x-cortex-apiiro: Apiiro
x-cortex-azure:
x-cortex-azure-devops:
x-cortex-bugsnag:
x-cortex-ci-cd:
x-cortex-checkmarx:
x-cortex-circle-ci:
x-cortex-coralogix:
x-cortex-dashboards: Charts embedded from , , or .
x-cortex-firehydrant:
x-cortex-git: , , ,
x-cortex-incident-io:
x-cortex-infra: ,
x-cortex-issues: , ,
x-cortex-k8s:
x-cortex-launch-darkly:
x-cortex-microsoft-teams:
x-cortex-oncall: , ,
x-cortex-owners: When you specify group as the type, you can use the following integrations as the group provider: , , , , , , , ,
x-cortex-rollbar:
x-cortex-rootly:
x-cortex-sentry:
x-cortex-semgrep:
x-cortex-servicenow:
x-cortex-slack:
x-cortex-slos: , , , , , ,
x-cortex-snyk:
x-cortex-static-analysis: , , ,
x-cortex-wiz:
The example below demonstrates how you can use each of the blocks in an entity's YAML file.
git.branches().all((branch) => branch.name.matches("(main|master|feat-.*|bug-.*|task-.*git.branchProtection() = nullgit.fileContents(“circleci/config.yml”).matches(“.*npm test.*”) - Enforce that a CI pipeline exists, and there is a testing step defined in the pipelinejq(git.fileContents("package.json"), ".engines.node") != nulljq(git.fileContents("package.json"), ".devDependencies | with_entries(select(.key == \"typescript\")) | length") == 0 or git.fileExists("tsconfig.json")jq(git.fileContents("package.json"), ".engines.yarn") == null or jq(git.fileContents("package.json"), ".engine.npm") = "please-use-yarn"git.reviews(lookback=duration("P7D")).length > 25jq(git.fileContents("package.json"), ".engines.yarn") == null or !(semver("1.2.0") ~= semverRange(jq(git.fileContents("package.json"), ".engines.yarn")))## API Spec and Version
openapi: 3.0.0
# Service Descriptors
# Required fields: info, title, x-cortex-tag
info:
title: <HUMAN_READABLE_SERVICE_NAME>
x-cortex-tag: <SERVICE_TAG>
description: <DESCRIPTION>
# Groups
# !Groups must contain only alphanumeric characters, and may not contain whitespaces!
x-cortex-groups:
- <GROUP_NAME>
- <GROUP_NAME>
- <GROUP_NAME>
# Owners
x-cortex-owners:
- type: group
name: my-team
provider: CORTEX # Use when referring to a team defined in Cortex; these teams do not map to identities from integrations
description: This is a description for this owner
- type: email
email: [email protected]
description: This is a description for this owner
- type: group
name: team-name
provider: ACTIVE_DIRECTORY | AZURE_DEVOPS | BAMBOO_HR | GITHUB | GITLAB | GOOGLE | OKTA | OPSGENIE | SERVICE_NOW | WORKDAY
# Also see the team entity example below
# Links
x-cortex-link:
- name: <HUMAN_READABLE_NAME>
type: <TYPE>
url: <URL_TO_LINK>
description: <DESCRIPTION>
## Note that type of OPENAPI/ASYNC_API will be displayed in the API Explorer tab in the Cortex UI
## Links support relative URLs
# Dashboards
x-cortex-dashboards:
embeds:
- type: <datadog | grafana | newrelic>
url: <URL>
# Custom Data
x-cortex-custom-metadata:
my-key: the value
another-key:
this: is
an: object
my-key-2:
value: the actual value for the key
description: This is the description
final-key:
- also
- use
- lists!
# Custom entities
# You cannot create a custom entity type via GitOps, but after creating the type in the UI or API, you can create custom entities via GitOps.
title: Sally S
description: Technical writer
x-cortex-tag: employee-sally
x-cortex-type: org-employees
x-cortex-definition:
location: San Diego
department: Engineering
# Parent and child relationships
x-cortex-type: team
x-cortex-children:
- tag: child-team-1
- tag: child-team-2
x-cortex-type: domain
x-cortex-parents:
- tag: parent-team-1
- tag: parent-team-2
# Entity relationships
x-cortex-relationships:
- type: relationship-type-name
destinations:
- tag: destination-entity-1
- tag: destination-entity-2
# Dependencies
# Required fields: x-cortex-tag, method (required if path present), path (required if method present)
x-cortex-dependency:
- tag: <TAG>
method: <HTTP_METHOD>
path: <PATH_FOR_METHOD>
description: <DESCRIPTION>
metadata:
tags:
- <TAG_1>
- <TAG_2>
prod: true
# Team configurations
title: Eng Team
x-cortex-tag: eng-team
x-cortex-type: team
x-cortex-team:
groups:
- name: eng-team
provider: OKTA
members:
- name: Eng Manager
email: [email protected]
notificationsEnabled: true
- name: Product Manager
email: [email protected]
notificationsEnabled: false
x-cortex-children:
- tag: infra-team
- tag: sre-team
# Domain configurations
x-cortex-type: domain
x-cortex-owners:
- type: GROUP
name: cortexapps/engineering
provider: GITHUB
interitance: APPEND | FALLBACK | NONE
x-cortex-children:
- tag: chat-service
tag: chat-database
# Integrations
# Apiiro
x-cortex-apiiro:
repositories:
- alias: alias-one
repositoryId: repository-one
- alias: alias-two
repositoryId: repository-two
applications:
- alias: alias-one
applicationId: application-one
- alias: alias-two
applicationId: application-two
# AWS Cloud Control types
x-cortex-infra:
aws:
cloudControl:
- type: AWS::RDS::DBInstance
region: us-west-2
accountId: "123456123456"
identifier: rds-example
# AWS ECS
x-cortex-infra:
aws:
ecs:
- clusterArn: <CLUSTER_ARN>
serviceArn: <SERVICE_ARN>
- clusterArn: <CLUSTER_ARN_2>
serviceArn: <SERVICE_ARN_2>
# Azure DevOps
x-cortex-git:
azure:
project: <project-name>
repository: <repository-name>
# Azure Resources
x-cortex-azure:
ids:
- id: /subscriptions/1fbb2da1-2ce7-45e4-b85f-676ab8e12345/resourceGroups/GROUP1/providers/Microsoft.Compute/disks/vm1_disk1_3d9f85717666435e9e87e4883d31a7e9
alias: my-default-alias # alias is optional and only relevant if you have opted into multi account support
- id: /subscriptions/1fbb2da1-2ce8-45e4-b85f-676ab8e12345/resourceGroups/GROUP2/providers/Microsoft.Compute/disks/vm1_disk1_3d9f85717666435e9e87e4883d31a7e0
alias: my-other-alias # alias is optional and only relevant if you have opted into multi account support
# BambooHR
x-cortex-owners:
- type: group
name: <TEAM_NAME>
provider: BAMBOO_HR
description: # optional
# Bitbucket
x-cortex-git:
bitbucket:
repository: <workspace>/<repo>
x-cortex-owners:
- type: group
name: <TEAM_NAME>
provider: BITBUCKET
description: # optional
# Bugsnag
x-cortex-bugsnag:
project: <PROJECT_KEY> # projectKey in Bugsnag
# Buildkite
x-cortex-ci-cd:
buildkite:
pipelines:
- slug: my-buildkite-pipeline-slug-1
- slug: my-buildkite-pipeline-slug-2
tags:
- tag: my-buildkite-tag-1
- tag: my-buildkite-tag-2
# Checkmarx
x-cortex-checkmarx:
projects:
- projectName: My Cool Project
- projectId: 1234
# CircleCI
x-cortex-circle-ci:
projects:
- projectSlug: circleci-projectslug # projectslug in CircleCI
alias: circleci-alias # alias is optional and only relevant if you have opted into multi account support
# ClickUp
x-cortex-issues:
clickup:
spaces:
- identifier: 123456789
identifierType: ID
folders:
- identifier: my-folder
identifierType: NAME
tags:
- name: tag a
- name: tag b
# Codecov
x-cortex-static-analysis:
codecov:
owner: org-name
repo: my-project
provider: AZURE_DEVOPS | BITBUCKET | BITBUCKET_SERVER | GITHUB | GITHUB_ENTERPRISE | GITLAB | GITLAB_ENTERPRISE
flag: flag
# Coralogix
x-cortex-coralogix:
applications:
- applicationName: my-app # application name tied to alert
alias: my-alias # alias is optional and only relevant if you have opted into multi account support
# Datadog
x-cortex-apm:
datadog:
serviceTags: # List of tags & values
- tag: <KEY>
value: <VALUE>
- tag: <KEY>
value: <VALUE>
. serviceName: <NAME IN DATADOG>
monitors:
- monitor-id
- monitor-id-2
x-cortex-slos:
datadog: # List of SLO ids
- id: slo-id-1
- id: slo-id-1
# Dynatrace
x-cortex-apm:
dynatrace:
entityIds:
- mock-service-id-1
- mock-service-id-2
entityNameMatchers:
- "foo.*"
x-cortex-slos:
dynatrace:
- id: slo-id-1
- id: slo-id-2
# Entra ID (Azure Active Directory)
x-cortex-owners:
- type: group
name: <TEAM_NAME>
provider: ACTIVE_DIRECTORY
description: # optional
# FireHydrant
x-cortex-firehydrant:
services:
- identifier: ASDF1234
identifierType: ID
- identifier: service-slug
identifierType: SLUG
# GitHub
x-cortex-git:
github:
repository: <org>/<repo>
basepath: <SERVICE_NAME> # optional
x-cortex-owners:
- type: group
name: <ORGANIZATION>/<TEAM> # Must be of form <org>/<team>
provider: GITHUB
description: # optional
# GitLab
x-cortex-git:
gitlab:
repository: <namespace>/<project>
basepath: <SERVICE_NAME> # optional
x-cortex-owners:
- type: group
name: Team Name
provider: GITLAB
description: This is a description for this owner
# Google
x-cortex-owners:
- type: group
name: <GROUP_NAME>
provider: GOOGLE
x-cortex-dependency:
gcp:
labels:
- key: my-key-1
value: my-value-1
- key: my-key-2
value: my-value-2
x-cortex-infra:
Google Cloud:
resources:
- resourceName: location/function
projectId: project1
resourceType: function
- resourceName: example-bucket
projectId: project1
resourceType: storage
x-cortex-slos:
gcp:
- projectId: cortex-gcp-integration
serviceId: iLE2e4HvR_iVlxAaBbCc12
- projectId: cortex-gcp-integration
serviceId: adfdfdafd
# Grafana
x-cortex-dashboards:
embeds:
- type: grafana
url: <embed_url_to_dashboard>
# incident.io
x-cortex-incident-io:
customFields:
- name: Entity
value: My Entity
alias: my-default-alias
- id: Entity_ID
value: my-second-entity
alias: my-other-alias
# Jira
x-cortex-issues:
jira:
labels:
- <LABEL1>
- <LABEL2>
components:
- <COMPONENT1>
projects:
- project1
# Optional: Override Cortex default Jira query
defaultJql: 'status = "In Progress"'
# Kubernetes
x-cortex-k8s:
deployment:
- identifier: namespace/name
cluster: dev # optional
- identifier: experiment/scratch
cluster: dev
- identifier: default/cortex
cluster: prod
argorollout:
- identifier: namespace/name
cluster: dev
statefulset:
- identifier: namespace/name
cluster: dev
cronjob:
- identifier: namespace/name
cluster: dev
# LaunchDarkly
x-cortex-launch-darkly:
projects:
- key: project-key
environments: # Optional
- environmentName: prod
- environmentName: staging
alias: alias-1 # alias is optional and only relevant if you have opted into multi account support
- tag: project-tag
environments: # Optional
- environmentName: prod
alias: alias-2 # alias is optional and only relevant if you have opted into multi account support
feature-flags:
- tag: feature-flag-tag
environments: # Optional
- environmentName: staging
alias: alias-3 # alias is optional and only relevant if you have opted into multi account support
# Lightstep
x-cortex-slos:
lightstep:
- streamId: <STREAM_ID>
targets:
latency:
- percentile: <PERCENTILE>
target: <TARGET>
slo: <SLO>
# Mend
x-cortex-static-analysis:
mend:
applicationIds:
- mend_id_1
- mend_id_2
projectIds:
- project_id_1
- project_id_2
# Microsoft Teams
x-cortex-microsoft-teams:
channels:
- name: team-engineering
teamName: engineering
description: This is a description for the engineering channel in Teams.
notificationsEnabled: true
# New Relic
x-cortex-apm:
newrelic:
applications:
- applicationId: <APP_ID>
alias: default-app
tags:
- tag: tagKey
value: tagValue
alias: default-app
x-cortex-dashboards:
embeds:
- type: newrelic
url: <FULL_URL_TO_DASHBOARD>
# Okta
x-cortex-owners:
- type: group
name: <GROUP_NAME> # group name in Okta
provider: OKTA
description: # optional
# OpsGenie
x-cortex-oncall:
opsgenie:
type: SCHEDULE
id: <SCHEDULE_ID> # Optionally, can use the Rotation UUID instead
x-cortex-owners:
- type: group
name: <GROUP_NAME>
provider: OPSGENIE
description: # optional
x-cortex-alerts:
- type: opsgenie
tag: <KEY>
value: <VALUE>
# PagerDuty
x-cortex-oncall:
pagerduty:
id: <SERVICE_ID> # Service ID
type: SERVICE
x-cortex-oncall:
pagerduty:
id: <SCHEDULE_ID> # Schedule ID
type: SCHEDULE
x-cortex-oncall:
pagerduty:
id: <POLICY_ID> # Escalation Policy ID
type: ESCALATION_POLICY
# Prometheus
x-cortex-slos:
prometheus:
- errorQuery: <query>
totalQuery: <query>
slo: <slo target number>
alias: my-prometheus-instance
name: my-slo-name
# Rollbar
x-cortex-rollbar:
project: <PROJECT_NAME> # projectName in Rollbar
# Rootly
x-cortex-rootly:
services:
- id: ASDF1234
- slug: service-slug
# Sentry
x-cortex-sentry:
projects:
- name: my-project # projectName in Sentry
- name: my-second-project
# Semgrep
x-cortex-semgrep:
projects:
- alias: my_org
projectId: 1234567
- alias: other_org
projectId: 7654321
# ServiceNow
x-cortex-servicenow:
services:
- tableName: cortex-services
id: 1
x-cortex-owners:
- type: group
name: My ServiceNow Team
provider: SERVICE_NOW
description: This is a description for this owner # optional
# Slack
x-cortex-slack:
channels:
- id: ABCDEF123
notificationsEnabled: true
description: This is a description for this Slack channel
- name: team-engineering
notificationsEnabled: true
description: A description for this Slack channel.
# Snyk
x-cortex-snyk:
projects:
- organizationId:<ORGANIZATION_ID>
projectId: <PROJECT_ID>
source: CODE
# SonarQube
x-cortex-static-analysis:
sonarqube:
project: <PROJECT_KEY> # projectKey in SonarQube
alias: sonarqube-alias
# Splunk Observability Cloud (SignalFX)
x-cortex-slos:
signalfx:
- query: <FULL_SFX_QUERY> # Ex. sf_metric:"jvm.memory.max" AND area:"nonheap"
rollup: <ROLLUP>
target: <TARGET>
lookback: <LOOKBACK>
operation: <OPERATION>
# Splunk On-Call (VictorOps)
x-cortex-oncall:
victorops:
type: SCHEDULE
id: <SCHEDULE_ID>
# Sumo Logic
x-cortex-slos:
sumologic:
- id: 000000000001234
- id: 000000000006789
# Veracode
x-cortex-static-analysis:
veracode:
applicationNames:
- My Application
- Second Application
sandboxes:
- applicationName: My Application
sandboxName: My Sandbox
- applicationName: Second Application
sandboxName: Second Sandbox
# Wiz
x-cortex-wiz:
projects:
- projectId: 01234567-e65f-4b7b-a8b1-5b642894ec37
# Workday
x-cortex-owners:
- type: group
name: workday-team-tag
provider: CORTEX
description: This is a description for this owner.
# xMatters
x-cortex-oncall:
xmatters:
id: engineering_group
type: SERVICEProject Contributors should be sufficient, or you can choose a custom security group that has Code write permissions.Learn more about permissions for Service Principals in Azure's documentation.
Client Secret: Enter the Client Secret for your app registration.
Azure Tenant ID: Enter the Directory (Tenant) ID for your app registration.
Host: Optionally, if you are using a self-managed setup, enter your hostname.
APPEND, FALLBACK, or NONE.Google Workspace is an ownership and cloud resources platform.
Integrating Cortex with Google allows you to:
Automatically discover and track ownership of Google entities
Pull in Service Level Objectives (SLOs) from Google Cloud Observability, and
Create that track progress and drive alignment on projects involving your Google resources and teams
Before getting started:
Create a .
In the Advanced settings, enable Domain-wide Delegation.
Under the Domain-wide Delegation setting, copy the client ID and store it in a secure location; you will need this in the next steps.
The service account should have the following permissions for each project to enable Google Cloud resources:
If you'd like to create a custom role with the minimum permissions required to enable this feature, add the following:
Enable the .
For Google Cloud resources, in each project, enable the following:
For each project in Vertex AI, enable the following:
In the , navigate to Security > API Controls > Manage Domain Wide Delegation. Click Add new.
Add the client ID you obtained in , and include the following scopes:
https://www.googleapis.com/auth/admin.directory.group.readonly
In Cortex, navigate to the :
Click Integrations from the main nav. Search for and select Google.
Click Add configuration.
Configure the Google integration form:
By default, a service will have dependencies on any resource with Google Cloud tag label = "service" and tag value = the service's Cortex tag. After saving your integration, you may customize the tag key name here by entering a new name into the Custom label key field. Leave it blank to use "service" as the key name.
Cortex supports pulling in the following entity types from Google:
You can configure automatic import from Google Cloud. Note that this setting does not include team entities.
In Cortex, navigate to .
Next to Auto import from AWS, Azure, and/or Google Cloud, click the toggle to enable the import.\
See the for instructions on importing entities.
Cortex can use Google Groups as an ownership provider, automatically syncing memberships from any Google Group mailing list.
By default, Cortex will try to automatically discover dependencies between your entities and Google Cloud resources with a matching label. By default the label key that will be matched is service, however you can customize this key value in the Google Cloud .
If you'd like to explicitly define these Google Cloud dependencies, the x-cortex-dependency field should be a map, defined as follows:
The value for name should be the full group email as defined in Google Groups.
Cortex uses the resource name and project ID to look up catalog entities in your Google Cloud account. Function resource names should be of the format location/function
The serviceID value is the value of the Unique ID listed on the .
After integrating with Google, you will see data from Google Cloud Observability on :
On an entity's overview page, see an overview of SLOs for the entity.
Click Monitoring > Google in an entity's sidebar to see more information about Google SLOs, including the SLO name, its targets, its status, the current value for that entity, and the period of time the SLO is being calculated for. For example, if the time listed is "7 days ago," then the SLO is looking at the time range starting 7 days ago to now.
With the Google integration, you can create Scorecard rules and write CQL queries based on GCP details, Google Cloud Observability SLOs, and Google teams.
See more examples in the in Cortex.
Ownership CQL
Cortex conducts an ownership sync for Google teams every day at 9 a.m. UTC.
By default, GCP service accounts are restricted to the project they were created in. If other projects don’t explicitly allow that service account to access their resources, Cortex can’t collect data from them. To work around this, you can configure a principal service account and associate it with multiple projects in GCP. Once the service account is linked to other projects, Cortex can use that service account to pull data from multiple GCP projects.
After creating a service account that is linked to a project, open your second project in GCP and go to IAM & Admin > IAM > Click +Add. Using the service account ID that you already created, add a principal to the project. Repeat these steps for each project.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: , or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
is a Git-based source code repository. You can use GitHub to share code with team members, track and manage changes to code over time, and collaborate on projects across your organization.
Integrating GitHub with Cortex allows you to:
Automatically discover and track ownership of GitHub entities
Follow a GitOps workflow with GitHub to manage your Cortex workspace
View information about your GitHub repositories on an
Artifact Registry → Artifact Registry Reader
BigQuery → BigQuery Metadata Viewer
BigQuery Connection → BigQuery Connection User
Cloud Asset → Cloud Asset Viewer
Cloud Asset → ListResource
Note: This permission is necessary to run services and jobs.
Cloud Functions → Cloud Functions Viewer
Cloud Pub/Sub → Pub/Sub Viewer
Cloud Resource Manager → Browser
Cloud Run → Cloud Run Viewer
Cloud SQL → Cloud SQL Viewer
Cloud Storage → Storage Admin
Composer → Composer User
Compute Engine, VM Instances → Compute Viewer
Kubernetes Engine → Kubernetes Engine Viewer
Memorystore Memcached → Cloud Memorystore Memcached Viewer
Memorystore Redis → Cloud Memorystore Redis Viewer
Monitoring → Monitoring Viewer
Service Accounts → View Service Accounts
Spanner → Cloud Spanner Viewer
VM Instances Vulnerabilities → OS VulnerabilityReport Viewer
VPC Serverless Connector → Serverless VPC Access Viewer
https://www.googleapis.com/auth/admin.directory.group.member.readonlyNavigate to the service account you created for this integration. Click Keys, then generate a key in JSON format.
Navigate to Admin Roles > Groups Reader and expand the "Admins" panel.
Click Assign service accounts then enter the email of the service account you created for this integration.
Domain: Enter your Google domain.
Service account email: Enter the email address for the service account.
Credentials JSON: Enter the service account JSON key you created in the previous steps.
Click Save.
Google Cloud Vertex AI Featurestore
Google Cloud Vertex AI Index
Google Cloud Vertex AI Model
Google Cloud Vertex AI Model Deployment Monitoring Job
Google Cloud Vertex AI Notebooks Instance
Google Cloud Vertex AI Pipeline Job
Google Cloud Vertex AI Platform Index Endpoint
Google Cloud Vertex AI Specialist Pool
Google Cloud Vertex AI Study
Google Cloud Vertex AI Tensorboard
Google Cloud Vertex AI Training Pipeline
Google Cloud Vertex AI Vision Application
Google Cloud Vertex AI Vision Cluster
Google Cloud Vertex AI Vision Index Point
Google Cloud Vertex AI Vision Operator
Google Cloud Vertex AI Vision Processor
Google Cloud Apigee Api
Google Cloud Apigee Instance
Google Cloud App Engine Service
Google Cloud Artifact Registry Repository
Google Cloud BigQuery Connection
Google Cloud BigQuery
Google Cloud Composer Environment
Google Cloud Functions
Google Cloud Kubernetes Engine Clusters
Google Cloud Kubernetes Engine Operations
Google Cloud IAM Service Account
Google Cloud Instance Group
Google Cloud HTTP(S) Load Balancing
Google Cloud Memorystore Memcached
Google Cloud Memorystore Redis
Google Cloud Project
Google Cloud Run Job
Google Cloud Run Service
Google Cloud Spanner Instance
Google Cloud Spanner Instance Config
Google Cloud SQL
Google Cloud Storage
Google Cloud Pub/Sub Topics
Google Cloud VM Instances
Google Cloud VPC Serverless Connector

On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in Troubleshooting with integration logs.
aiplatform.datasets.get
aiplatform.datasets.list
aiplatform.endpoints.get
aiplatform.endpoints.list
aiplatform.featurestores.get
aiplatform.featurestores.list
aiplatform.indexEndpoints.get
aiplatform.indexEndpoints.list
aiplatform.batchPredictionJobs.get
aiplatform.batchPredictionJobs.list
aiplatform.modelDeploymentMonitoringJobs.get
aiplatform.modelDeploymentMonitoringJobs.list
aiplatform.trainingPipelines.get
aiplatform.trainingPipelines.list
aiplatform.pipelineJobs.get
aiplatform.pipelineJobs.list
aiplatform.specialistPools.get
aiplatform.specialistPools.list
aiplatform.tensorboardExperiments.get
aiplatform.tensorboardExperiments.list
aiplatform.studies.get
aiplatform.studies.list
aiplatform.apps.get
aiplatform.apps.list
aiplatform.indexes.get
aiplatform.indexes.list
aiplatform.models.get
aiplatform.models.list
aiplatform.tensorboards.get
aiplatform.tensorboards.list
iam.serviceAccounts.get
apihub.apiHubInstances.get
apihub.apis.get
apihub.apis.list
appengine.services.get
appengine.services.list
artifactregistry.repositories.get
artifactregistry.repositories.list
bigquery.connections.get
bigquery.connections.list
bigquery.datasets.get
bigquery.routines.get
bigquery.routines.list
cloudasset.assets.listResource
cloudfunctions.functions.get
cloudfunctions.functions.list
cloudsql.instances.get
cloudsql.instances.list
composer.environments.get
composer.environments.list
compute.urlMaps.list
compute.urlMaps.get
compute.instances.list
compute.instances.get
compute.instanceGroups.list
compute.instanceGroups.get
container.clusters.get
container.clusters.list
container.operations.get
container.operations.list
iam.serviceAccounts.get
iam.serviceAccounts.list
memcache.instances.list
memcache.instances.get
monitoring.services.get
monitoring.services.list
monitoring.slos.get
monitoring.slos.list
monitoring.timeSeries.list
notebooks.instances.get
notebooks.instances.list
osconfig.vulnerabilityReports.get
pubsub.topics.get
pubsub.topics.list
redis.instances.list
redis.instances.get
resourcemanager.projects.get
resourcemanager.projects.list
run.jobs.list
run.jobs.get
run.services.list
run.services.get
spanner.instances.get
spanner.instances.list
spanner.instanceConfigs.get
spanner.instanceConfigs.list
storage.buckets.get
storage.buckets.list
visionai.applications.get
visionai.applications.list
visionai.processors.get
visionai.processors.list
visionai.operators.get
visionai.operators.list
visionai.clusters.get
visionai.clusters.list
vpcaccess.connectors.get
vpcaccess.connectors.list
x-cortex-dependency:
gcp:
labels:
- key: my-key-1
value: my-value-1
- key: my-key-2
value: my-value-2x-cortex-owners:
- type: group
name: [email protected]
provider: GOOGLE
description: This is a description for this owner # optionalx-cortex-infra:
Google Cloud:
resources:
- resourceName: location/function
projectId: project1
resourceType: function
- resourceName: example-bucket
projectId: project1
resourceType: storagex-cortex-slos:
gcp:
- projectId: cortex-gcp-integration
serviceId: iLE2e4HvR_iVlxAaBbCc12
- projectId: cortex-gcp-integration
serviceId: adfdfdafdgcp.details() != nulljq(gcp.details(), ".resources[0].labels | any(\"origin\")")slos().all((slo) => slo.passing) == trueslos().filter((slo) => slo.name.matchesIn("latency") and slo.sliValue >= 0.9999).length > 0ownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)ownership.teams().all(team => team.description != null and team.isArchived == false)In an entity's Code & Security section, see vulnerabilities from GitHub Advanced Security (Code scanning, Dependabot alerts, CodeQL, and Secret scanning)
View information about pull requests and work items in the engineering homepage
Use GitHub metrics in Eng Intelligence to understand key metrics and gain insight into services, incident response, and more
Create Scorecards that track progress and drive alignment on projects involving your repositories
You can also optionally integrate GitHub Copilot with Cortex to:
Track Copilot adoption and impact within Eng Intelligence
If you connect Cortex via a custom GitHub app, it must be configured with a fine-grained personal access token containing the minimum permissions listed below.
Note: The Cortex GitHub app is preconfigured with these permissions.
Permission
Requirement
Purpose(s) in Cortex
Actions
Read & write
Read workflow run information for Git-based CQL rules
Artifact information for actions
Administration
Read & write
Create repositories
Code scanning alerts
Read-only
Get vulnerability information for Git-based CQL rules
Commit statuses
Read & write
Read commits for an entity's Git metadata
Read commits for Git-based CQL rules
Show pending status messages on the OpenAPI incompatibility check
Administration
Read & write
Create repositories
Pull in Copilot data for
Members
Read & write
Read membership information for ownership and team composition
Write permission used in
Secrets
Read & write
Optionally write repo secrets after creating new repo
There are multiple options for connecting Cortex to your GitHub instance:
Through Cortex's official GitHub app
Note: This is supported for use with a single organization in GitHub.
Through a custom GitHub app
By using Cortex's official GitHub app or a custom GitHub app, users can tag entities with Git details and enable GitOps-style configuration of data in Cortex.
Using a personal access token
Using Cortex Axon Relay, a relay broker that allows you to securely connect your on-premises GitHub data.
If your GitHub setup involves multiple organizations, you can add multiple GitHub apps, use a personal access token that has access to all orgs, or create multiple configurations with corresponding aliases.
See the tabs below for instructions on each of the GitHub integration options.
Configure GitHub with the Cortex GitHub app
Cortex's official GitHub app is the easiest way to connect your GitHub instance. It is preconfigured with the permissions needed to use this integration. Note that it is not available for Cortex Server.
To set up the app:
In Cortex, navigate to the GitHub settings page:
Click Integrations from the main nav. Search for and select GitHub.
On the GitHub settings page, next to cortex, click Install.
Follow the prompts, then click Install & Authorize.
Cortex's GitHub app is preconfigured with:
Permissions for , , and the .
Webhooks to enable .
Support for using as an ownership provider.
The app comes with a built-in linter, which validates the format of a given cortex.yaml file and checks Cortex-specific items. However, the linter DOES NOT validate data correctness. For example, the linter will confirm that the format of a group block is correct, but will not check that the group exists.
Configure GitHub with a custom app
If you're using Cortex Server, or if you don't want to use the official Cortex app, you can connect a custom GitHub app.
Make sure you have configured the permissions listed above under .
Step 1: Register the custom app in GitHub
. When you're creating the app, make sure to follow these steps:
Disable "Expire user authorization tokens." (Cortex does not support this OAuth workflow yet.)
Configure GitHub with a personal access token
Prerequisites
Before getting started, make sure your has, at minimum, the repo and read:org permissions.
Note: Beyond the minimum permissions indicated above, many scenarios will require that the user who generated the personal access token have organization ownership permissions within GitHub.
Configuration
In Cortex, navigate to the :
Configure GitHub with Cortex Axon Relay
See for instructions. Make sure to follow the GitHub-specific instructions for the docker-compose.yml file.
Configure the integration for multiple GitHub accounts
The GitHub integration has multi-account support. You can add a configuration for each additional organization, instance, or account by repeating the process above.
Each configuration requires an alias, which Cortex uses to correlate the designated organization, instance, or account with registrations for various entities. Registrations can also use a default configuration without a listed alias. You can edit aliases and default configurations from the GitHub page in your Cortex settings. Select the edit icon next to a given configuration and toggle Set as default on. If you only have one configuration, it will automatically be set as the default.
Cortex supports mapping multiple identities for a single user if you have multiple configurations of GitHub. See the Identity mapping documentation for more information.
See the Create services documentation for instructions on importing entities.
Repository
You can define a GitHub repository for a given entity by adding the x-cortex-git block to the entity's descriptor. When you define a repository, Cortex checks for Security Advisory vulnerabilities from the GraphQL API and Advanced Security vulnerabilities from the Rest API.
repository
GitHub repository in the form /
✓
basepath
Subdirectory for the entity if it is in a monorepo. Note that setting a basepath filters the vulnerabilities that appear in Cortex; Advanced Security vulnerabilities will not appear.
alias
Alias for the configuration in Cortex (only needed if you have opted into multi-account support)
Only one repository can be defined for in a given entity's YAML in the x-cortex-git block. Users looking to list additional repositories without the full functionality of GitOps can define the repos as custom data.
Ownership
You can define the following block in your Cortex entity descriptor to add your GitHub teams. Be sure to include both your GitHub organization name and the team name in the name field.
type
Ownership type; must be defined as group for GitHub teams
✓
name
GitHub team name in the form /Team names are generally converted to lowercase with - separators (Team Name would be cortex/team-name), but you can verify your exact name from the GitHub permalink
✓
provider
Name of integration (in this case, GITHUB)
✓
description
Description for the GitHub team
Multiple GitHub organizations are not supported for ownership, and Cortex will use the default configuration when fetching teams.
Cortex maps users' email addresses to discovered GitHub accounts, so you never need to define email ownership in an entity descriptor. Users must be members of GitHub teams to be pulled in to Cortex.
You can confirm users' GitHub accounts are connected from GitHub identity mappings in settings.
The GitHub integration will populate the Repo and Language detail blocks on an entity's details page. If a GitHub team has been defined as the owner for an entity, it will also appear in the Owners block.
Vulnerabilities appear in the Vulnerabilities block under Code & security on an entity page overview.
Click Code & security in an entity's sidebar to view the full list of vulnerabilities for an entity. Cortex checks for:
Security Advisory vulnerabilities from the GraphQL API
GitHub Advanced Security vulnerabilities
Cortex pulls data from code scanning, Dependabot alerts, CodeQL, and Secret scanning.
Dependency reviews are not supported.
GitHub Advanced Security vulnerabilities are not surfaced for monorepos.
You can query for vulnerabilities with CQL and create Scorecard rules based on security metrics. See Scorecards and CQL below.
Recent commits appear at the top of an entity's overview page.
You can also click Events in the entity's sidebar to see all commits and releases associated with that entity. Each is hyperlinked to the commit or release page in GitHub and includes a timestamp.
You can access more detailed information pulled from GitHub in the Repository page in the sidebar. At the top of the page, you'll find the repo(s) associated with that entity and the most-used language in files for that entity. In the Top contributors block, you'll find the three users who have contributed the most code and the number of their contributions.
In the Commits section, you'll find the 10 most recent commits and metadata about each. Below Commits is the Recent releases section, which includes the 5 most recent releases.
From the Issue tracking page in the entity's sidebar, you can find a list of open GitHub issues. Each issue will show the number, title, assignees, and date created.
From the CI/CD > GitHub workflows page in the entity's sidebar, you can find a history of GitHub workflow runs for the past week. Each run is tagged with its status: IN_PROGRESS, COMPLETED, SUCCESS, CANCELLED, FAILURE, PAUSED.
The GitHub workflows page displays data about workflows in GitHub, not Workflows initiated via Cortex's Workflows tool.
When a GitHub team is registered with a team entity, Cortex will pull GitHub users in to the Members tab. When available, Cortex will pull in the profile picture and email address for each user.
The GitHub integration enables Cortex to pull information about pull requests and issues into the homepage. You can find your open pull requests, any pull requests assigned to you for review, and any issues assigned to you.
Pull requests and issues from GitHub are refreshed every 2 minutes.
The Eng Intelligence tool uses pull request data from GitHub to generate metrics:
Average PR open to close time
Avg time to first review
Avg time to approval
PRs opened
Weekly PRs merged
Avg PRs reviewed/week
Avg commits per PR
Ave lines of code changed per PR
Eng Intelligence also pulls in data from Copilot to show AI impact in the Copilot Dashboard.
You can read more about how Eng Intelligence tracks metrics for teams and users in the Eng Intelligence documentation.
To add deployments for your Github related entity, you can send a deployment event to the Cortex API.
With the GitHub integration, you can create Scorecard rules and write CQL queries based on GitHub data.
See more examples in the CQL Explorer in Cortex.
Ownership CQL
External repositories
By default, each GitHub rule is evaluated on the repository defined in a given entity descriptor. If the base path parameter has been set, CQL rules will automatically scope to the base path subdirectory.
To evaluate the rule for a service for an external repository, pass the repo identifier in the git(repoIdentifier: Text) command (e.g. git("github:org/repositoryName")).
This can be combined with other CQL rules. For example, a rule based on a dynamic external repository with custom data would be git("github:" + custom("my-custom-repo")).fileExists("README.md").
Cortex conducts a background sync of GitHub identities every day at 10 a.m. UTC. Pull requests and issues are refreshed about every 10 minutes.
I'm getting this error: "{"message":"Not Found", "documentation_url":"https://docs.github.com/rest/repos#get-a-repository"}".
If you've set up multiple GitHub accounts/organizations, Cortex will not be able to identify the correct one unless the alias variable is defined.
What if I have multiple email addresses set in my GitHub account?
Cortex will only detect the primary email address associated with your GitHub account if it is public.
If Cortex is not correctly pulling in user emails, ensure the given user(s) have allowed their email address to be public. Make sure the "Keep my email address private" setting is unchecked in the user's personal GitHub settings.
My ownership isn't being automatically mapped through GitHub.
If the email address associated with your Cortex account is not the same as your GitHub email address, you need to add your Cortex email address to the Public email dropdown in GitHub settings.
Github OAuth, which you can configure in Cortex user settings, allows you to link your GitHub username with your Cortex account, even if you don't have a public email set up on GitHub.
The following options are available to get assistance from the Cortex Customer Engineering team:
Email: [email protected], or open a support ticket in the in app Resource Center
Slack: Users with a connected Slack channel will have a workflow added to their account. From here, you can either @CortexTechnicalSupport or add a :ticket: reaction to a question in Slack, and the team will respond directly.
Don’t have a Slack channel? Talk with your Customer Success Manager.
Packages are automatically scraped from your Git repos or they can be submitted via the . The package file must be in the root of your repository — or, if you're using basepath, in the root of the subdirectory — to be scraped by Cortex. You can query an entity's packages in using packages().
To view packages, click Packages in the entity's sidebar.
The following package types are automatically scraped from repositories:
JavaScript / Node.js: package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
On the integration settings page, click the Logs tab to view logs from the last 7 days. Learn more in .
git.numOfRequiredApprovals() > 0git.numOfRequiredApprovals() < 1git != nullgit.defaultBranch().matches("main")git.fileContents("circleci/config.yml").matches(".*npm test.*")git.fileExists("README.md")git.fileExists("yarn.lock") OR git.fileExists("package-lock.json")git.fileExists("*Test.java")git.numOfVulnerabilities() == 0git.vulnerabilities().length < 5git.vulnerabilities(severity=["CRITICAL", "HIGH"], source=["GITHUB_ADVANCED_SECURITY"]).length < 1git.hasCortexYaml() == trueownership.teams().length > 0ownership.allOwners().all((member) => member.email != null)ownership.teams().all(team => team.description != null and team.isArchived == false)x-cortex-git:
github:
repository: cortex/docs
basepath: myService
alias: myAppx-cortex-custom-metadata:
second-git-repo:
- `/`
third-git-repo:
- `/`x-cortex-owners:
- type: group
name: cortex/engineering
provider: GITHUB
description: This is a description for this GitHub team that owns this entity.Select "Request user authorization (OAuth) during installation."
Callback URL: https://app.getcortexapp.com/github/redirect/{alias}
Make sure to use the GitHub configuration alias and not the tenant name in the URL.
Webhook URL: https://api.getcortexapp.com/api/internal/v1/github/webhook
Add a webhook secret of your choosing that will be identical to the webhook secret token configured later in Cortex settings.
Set the repository and organization permissions outlined in the configuration modal.
Check Push and Check suite under Subscribe to events.
After the app has been created, generate a client secret and private key.
Step 2: Configure the custom app in Cortex
In Cortex, navigate to the GitHub settings page:
Click Integrations from the main nav. Search for and select GitHub.
Click Add configuration, then for the type, select GitHub app.
Fill in the form:
Alias: Enter the name Cortex will associate with a given configuration.
Application ID: Enter the ID for your custom GitHub ap.
Client ID: Enter the unique assigned to your app during registration.
Client secret: Enter the unique client secret assigned to your app during registration.
Click Save.
On the GitHub Settings page in Cortex, under Webhook, choose your new configuration alias and enter the same Secret token that was entered in GitHub during the app configuration.
On the GitHub Settings page in Cortex, next to your custom app configuration's name, click Install.
Click Integrations from the main nav. Search for and select GitHub.
Click Add configuration.
In the upper right corner of the modal, click the dropdown and select Personal access token.
Fill in the form:
Alias: Enter a name that Cortex will associate with a given configuration.
Token: Enter the Personal access token generated in GitHub.
API endpoint (for GitHub enterprise): Enter the endpoint root URL for self-managed GitHub setups.
Click Save.
Python: requirements.txt, pipfile.lock
.NET (C#): packages.lock.json
Java: pom.xml
Go: go.sum
All other files of these types can be added via the packages API.
Contents
Read & write
Read cortex.yaml, cortex-properties.yaml, and package/OpenAPI files
Read Git rules
Create file contents
Custom properties
Read & write
Used in Workflows
Checks
Read
Used to create and update check runs for linting and validation workflows, such as the cortex.yaml linter on pull requests.
Dependabot alerts
Read-only
Read vulnerability information for Git CQL rules (only relevant if using Dependabot)
Deployments
Read & write
Used in Workflows
Issues
Read & write
Read associated issues with repositories for populating entity Git integration and for Git CQL rules
Create new issues based on Initiatives
Metadata
Read-only
Read associated data with repositories for populating entity Git integration and for Git CQL rules
Pull requests
Read & write
Read pull request data for Git CQL rules and developer homepage "My PRs" tab
Comment if there are breaking OpenAPI changes on a PR
Secret scanning alerts
Read-only
Read vulnerability information for Secret scanning
Single file
Read & write (path to cortex.yaml)
Read cortex.yaml files
Create cortex.yaml files
Workflows
Read & write
Write in GitHub actions files

git.branches().all((branch) => branch.name.matches("(main|master|feat-.*|bug-.*|task-.*)"))git.branchProtection() != nullgit.branchProtection() = nullgit.commits(branchName="security-fixes").length < 3jq(git.fileContents("package.json"), ".engines.node") != nulljq(git.fileContents("package.json"), ".devDependencies | with_entries(select(.key == \"typescript\")) | length") == 0 or git.fileExists("tsconfig.json")jq(git.fileContents("package.json"), ".engines.yarn") == null or jq(git.fileContents("package.json"), ".engine.npm") = "please-use-yarn"git.fileExists(".prettierrc.json") OR git.fileExists(".eslintrc.js")git.numOfVulnerabilities(severity=["CRITICAL"]) == 0git.numOfVulnerabilities(severity=["WARNING"]) == 0git.lastCommit().freshness < duration("P1M")git.lastCommit().freshness < duration("P7D")git.pullRequests(lookback=duration("P14D")).length < 3git.reviews(lookback=duration("P7D")).length > 25git.workflowRuns(conclusions=["SUCCESS"], statuses=["COMPLETED"], lookback=duration("P14D")).length > 0(git.workflowRuns(conclusions=["SUCCESS"], lookback=duration("P1D")).length) / (git.workflowRuns(lookback=duration("P1D")).length) * 100jq(git.fileContents("package.json"), ".engines.yarn") == null or !(semver("1.2.0") ~= semverRange(jq(git.fileContents("package.json"), ".engines.yarn")))Private key: Enter the private key to authenticate with your GitHub app.
Public link: Enter the public URL of your GitHub app.
API endpoint (for GitHub enterprise): Enter the endpoint root URL for self-managed GitHub setups.
