We set rules and criteria to determine what constitutes a “service” in your repositories. Then, once you integrate your git provider(s), we will pull everything that meets these criteria into OpsLevel, consolidating everything we find into a proposed catalog.

Service Detection identifies all services within your git repositories and pulls them into OpsLevel as suggested catalog objects or items—making it faster and easier than ever to get started. Learn more about Service Detection in our docs.

You will need to approve or ignore each entry we surface—you can do this individually or in bulk. If you ignore a service, it goes into an ignored state that can be revived later.

Discovered Services uses a webhook in your CI pipeline to monitor what it’s being deployed to. Service Detection monitors everything in your git repo(s) to identify and entire catalog, whether or not a deploy is happening.

OpsLevel’s AI assistance generates automated service descriptions using the contents of your repository files and data from across your services architecture.

Many services are missing descriptions in OpsLevel. This information offers critical context for broader engineering teams, but motivating service owners to keep them updated is a chore. With AI-generated service descriptions you get meaningful context added to your catalog automatically, without the hassle.

The feature is currently disabled by default on all existing customer accounts. As of Thursday, October 12, 2023, it will be enabled by default for new accounts. Access to the feature can be turned on (or off) at any time through the settings panel in your account.

In addition to OpsLevel’s typical code-scanning functionality, we’re using a large-language model hosted by OpenAI. If this feature is enabled, your repository contents could be submitted to the OpenAI API for analysis. OpenAI will read any repository content; it prefers documentation, but it will also read code.

We then leverage OpenAI’s GPT o1 and o1-mini to generate proposed service descriptions for any catalog entity missing one, based on the context it’s found in your linked repositories. 

‍

We have an agreement with OpenAI that none of your code is stored at rest permanently. Per OpenAI API Data Usage Policies, OpenAI will not use your data to train their models.

The agent transiently scans your documentation and code and uses it to make an inference about what a service’s description should be.

Similar to our repo checks, after computing a result, the original input code and documentation is eventually discarded.

‍

We care deeply about who has access to your code and where it is stored. We handle your data in accordance with our Privacy Policy and data protection regulations. As always, our complete subprocessor list is available on our trust portal.

‍

Documentation as Code (docs-as-code) refers to the philosophy of writing documentation with the same tools as code. It also means doc writers (developers themselves or dedicated technical writers) follow the same workflows as development teams. This approach can be applied to internal and external software documentation. Learn more about docs-as-code here.

OpsLevel is an internal developer portal that gives teams self-service access to the tools and knowledge they need to move faster without sacrificing standards. Engineering leadership at some of the best companies in the world rely on OpsLevel to help them drive standardization while improving developer experience and efficiency.

With Service Creation, Platform/SRE teams are able to define reusable templates that contain all the necessary scaffolding to set up a new service. Developer teams can then use these templates by entering in template variables to configure their service. This accelerates the pace at which developer teams can get started, while allowing platform teams to encode best practices and organizational standards into the services right from initial creation. Learn more about this in our docs.

You must be storing your internal docs in a git repo that's integrated with OpsLevel in order to use this feature. But our Checks and Campaigns can help you drive this change within your organization—your developers will thank you!

No, there is nothing for developers to install or maintain locally. They only need access to OpsLevel. Learn more about the benefits of Service Creation on our blog.

Cookiecutter is entirely language agnostic. Templates can be defined to create new services of any kind.

No. Tech Docs is designed strictly for internal docs. Only authenticated users of your OpsLevel instance will be able to access Tech Docs.

OpsLevel is priced based on the number of developers using the portal. We also can customize pricing within your unique needs and offer volume discounts. Please book a meeting to learn more.

OpsLevel admins can import any Cookiecutter template into their OpsLevel template library. Template definition happens outside of OpsLevel, before a template is imported. Learn more in our docs.

External docs solutions, or docs solutions that aren't designed for developers, tend to create silos. When information is siloed like this it often gets forgotten or goes stale.

With Tech Docs, the opposite happens. Your internal docs are centralized and live alongside all the important metadata in your service catalog, like ownership, dependencies, or Service Maturity level. Tech Docs are easily discoverable and searchable by all developers. Tech Docs are more visible to the entire organization, and so better updated and maintained.

We provide support over email, dedicated per-customer Slack channels, and via in-app chat.

OpsLevel is SOC2 Type 2 certified. More details are available on our security page.

If OpsLevel is a potential fit for your organization, we’ll book a session with someone from our team. During the meeting, we can give a quick look at the product, dive into the problems you're trying to solve, and answer any questions you might have.