Going further with Cortex

With the foundation laid and the core features in place, you're ready to take Cortex further. This article covers the capabilities that help you tailor Cortex to your organization.

Tracking ownership with teams

In Cortex, teams play two roles: they're entities that represent your organization, and they're the owners of entities in your catalogs. Ownership is central to how Cortex works as organizations rely on it to establish clear accountability for services, data, and everything else in the catalog. It also determines who receives notifications from Cortex, including on-call changes, Scorecard updates, and other alerts. Like other entities, teams can be evaluated with Scorecards, enriched by integrations, and extended with custom data. They can be organized into hierarchies, and their activity can be tracked and analyzed in Eng Intelligence. You can create teams manually in Cortex or pull them in automatically from your integrations.

Building your own plugin

When Cortex doesn't have exactly what you need out of the box, plugins let you build it yourself. Use them to support custom workflows, surface data from internal systems, or connect tools Cortex doesn't natively integrate with. Each plugin is a single HTML file rendered inside an iframe within Cortex. Plugin proxies handle CORS restrictions and can add custom headers and secrets to outbound requests, making it easy to work with external APIs. Plugins also get contextual information about where they're running in the app, so they can adapt what they show.

Managing external docs

Documentation is often one of the biggest pain points in a growing engineering org—scattered across wikis, Google Docs, repos, and shared drives, with no easy way to tell what's current or relevant. Cortex solves this by becoming the source of truth for your external docs. You can aggregate documentation onto the entities it relates to, so a service's runbook, architecture notes, and onboarding guide all live right next to its ownership and health information. See Adding external documentation for more information.

Using GitOps with Cortex

Instead of managing everything through the Cortex UI, you can take a GitOps approach. GitOps is a practice that treats configuration the same way engineering teams already treat code: stored in a Git repository, reviewed through pull requests, and deployed automatically when changes are merged. Applied to Cortex, that means your entities, Scorecards, and Workflows are defined as descriptor files in a repo you own. When someone opens a PR to update a descriptor, your team reviews it like any other change; once it's merged, Cortex picks it up and syncs the update automatically. This approach offers several advantages:

• Version-controlled metadata - Every change has history, context, and an author.

• A single source of truth - The repository where your code lives also holds the definitions of how that code is represented in Cortex.

• Full ownership of your data - Descriptors live in your repository, not locked inside the UI.

• Clear auditability - GitOps logs let you monitor and track every sync, making it easy to debug issues or review changes.