Repo File Checks

After setting up a Git Repository integration, OpsLevel can continuously scan your code repositories and verify all of the operational best practices you’ve defined.

Along with the integration comes two new checks:  the Repo File Check, and the Repo Search Check.  This article describes the former, as well as some of the cool things you can do with it.

The Repo File Check

With the Repo File Check, you can verify the existence or contents of a file in your repo.

Why would you want to do that?  Well, let’s see some examples of different kinds of checks you can build:

Repo File Check Examples

Verify Ruby version

You can verify that a repo is using a given Ruby version using either .ruby-version or Gemfile.lock. For example:

Filename Predicate Contents
.ruby-version equals 2.6.0
Gemfile.lock contains    ruby 2.6.0

Verify Ruby library

Like verifying the Ruby version, you can look at Gemfile.lock to verify a particular library is installed.

Filename Predicate Contents
Gemfile.lock contains     rails (5.2.0)

Verify Rails is not logging passwords

Part of the Rails Security Guide talks about how to set up Rails to not log passwords. You can verify that your apps have this enabled:

Filename Predicate Contents
config/initializers/filter_parameter_logging.rb contains config.filter_parameters << :password

Verify Python version

Much like verifying the Ruby version, if you use Pyenv, you can verify the version of Python with .python-version.

Filename Predicate Contents
.python-version equals 3.7.0

Verify Python Library

If you use pip and requirements.txt, you can validate that a given Python library version is used. Be sure to freeze your requirements beforehand with pip freeze > requirements.txt.

Filename Predicate Contents
requirements.txt contains Django==2.1.7

Verify Java library

If you use Apache Ivy, you can easily validate the presence of a given Java library.

Filename Predicate Contents
ivy.xml contains <dependency org="apache" name="commons-lang" revision="2.0">

Verify exists

It’s good practice that every repo should have a README.  Just create a check that validates that this file exists, without looking into its contents.

Verify CircleCI is setup properly

If you use CircleCI, you can verify any aspect of your continuous integration. For example, you may want to verify that linting is enabled with Danger or that you’re running tests with RSpec.

Filename Predicate Contents
.circleci/config.yml contains bundle exec rspec
.circleci/config.yml contains       - run: danger

Verify a recent version of Kubernetes

Older versions of Kubernetes had an apiVersion of apps/v1beta2. You can verify that your repos are all using the latest version of Kubernetes in their deployments.

Filename Predicate Contents
deployment.yaml contains apiVersion: apps/v1

And more!

Ok, those were just some examples to get the creative juices flowing.  But there’s tons more you can do with Repo file checks.  If you have any questions, or just come up with some interesting checks you want to share, hit us up at

OpsLevel Integrates with GitHub (and Bitbucket)

You likely use a myriad of cloud-based tools to operate your services.  At OpsLevel, part of our master plan is bringing various data points from all of these tools to help you gain insights and build more reliable software. We’re proud to announce our latest step on this journey with our new Github and Bitbucket integrations.

GitHub Integration

Our GitHub integration unlocks a lot of new functionality in OpsLevel:

  • New checks are available that can dive deep into your codebase.  Do you want to make sure all your Python services are on a modern version of the language?  Or that no services are using an old library that you’re trying to deprecate?  Or that every service has a CircleCI config file?  You can do that.
  • OpsLevel will stay up-to-date by reading the opslevel.yml files in your services’ repos.  Now you don’t have to go to OpsLevel’s UI to update your service metadata, and can make changes to service metadata using pull requests.

To set up a GitHub or Bitbucket integration, go to our Integrations tab, and hit “New Integration”. Then, look for the integration you want and hit “Add Integration.”

Follow the prompts, tie it to your organization, and OpsLevel will soon show you a list of all repositories it has access to.

Map a Repository to a Service

For the Repo-specific features to work, OpsLevel needs to know which services map to which repos.

If you’ve added an opslevel.yml file to your repo, it will automatically create a service in OpsLevel and do the mapping for you.  You can skip the below.

But if you have already created a service in OpsLevel, then you should manually map it to a specific repo.  To do this, simply add a link to your repo in that service’s Operations Center.

If found, OpsLevel will show a green pill indicating that the service is connected and that it is actively monitoring that repo.

(Note:  if you have a mono-repo, just add a link directly to the subfolder that represents your service.)

Have fun

Now you can start setting up some Repo File Checks, Repo Search Checks, and start using opslevel.yml to keep OpsLevel data up to date.

If you have any questions or are interested in trying out OpsLevel, hit us up at

Checks and Checklists

OpsLevel has become a lot more powerful with the addition of our newest features:  Checks and Checklists.

Now you can actually codify your best-practices around building and operating microservices, and then view how these practices are being followed across your entire architecture.


A checklist is, obviously, a list of checks.  But a checklist also comes with “conditions”:  these let you define which of your services this checklist should apply to based on those services’ properties.

To create a checklist:  navigate to the Checklists tab, and click New Checklist.

Now define your checklist’s conditions.  Maybe you want to create a checklist that only runs against those services that are written in Ruby?  Or a checklist that only applies to Tier 1 and Tier 2 services?  You can do that!


Checks are the meat of your checklist.  Checks define what you want to be true with how your services are built and operated.

There are a number of different checks you can define, and most have a lot of options.  You can define a simple ownership check (to make sure none of your services are orphaned), or you can set up tool checks – that make sure your services are using certain operational tools.  You can even set up checks that dive into your codebase with our Git Repository integration.  Go ahead and create some!



Now that you have checklists defined with various checks, you can see – on your services’ detail pages – whether these checks are passing or failing for each of the particular services they apply.

But you can also get a view of your operational health across all your services with our reports feature.  Moving to Kubernetes?  Below is an example report showing all the services passing and failing a Kubernetes tool check.


If you have any questions or are interested in trying out OpsLevel, hit us up at