Getting Started with Checks

Learn how checks can be used to evaluate and score your software components.

Checks are the building blocks of measuring component maturity in OpsLevel. Checks explicitly define what you want to be true about how your software components are built and operated.

With OpsLevel checks, you can verify that components:

  • Are using a particular version of a library or framework
  • Have migrated to a new third party tool (e.g., are all of our components off Splunk?)
  • Have a low number of production incidents or library vulnerabilities

And a whole lot more.

OpsLevel checks can dive into your codebase (with our Git Repository Integration), parse through any JSON payload sent to us (with our Custom Event Integration), or ensure manual processes are regularly met (e.g., has the component been signed off by the architecture review board?).

Checks can be:

  • Added to your rubric and evaluated to determine the maturity of your components. To learn more about how levels are generated from your rubric, see the Maturity Report documentation.
  • Added to a campaign to define the changes the campaign is meant to bring about, and to evaluate how components are progressing with implementing those changes.

Here is an example of a rubric containing checks.

Rubric with Checks

There are a few options that are shared between all checks types.

Check Status: Enabled / Disabled / Enable Later

Enabled checks are applied against matching components and contribute to the levels of those components.

Disabled checks are not visible in the component's Maturity Report tab and do not affect the levels of your services. However, for a check owner, you can still view individual reports for disabled checks.

Enable Later checks can be scheduled with a future enable date. These checks are visible in the matching component's Maturity Report tab but do not affect the levels of components until they are enabled. Component owners can see the scheduled checks and they can proactively plan or work towards completing these checks.

Owners and Notes

Everything in OpsLevel should have ownership, including checks. Assigning a check owner lets component owners know who to contact for questions about a check on their component. As a check owner, you can provide notes to offer component owners additional details that might be important about that specific check.

Checks can apply to all or only a subset of components

Filters allow you to control which components you want a check to apply to (e.g., all JavaScript services; all Tier 1 components with internet-facing: true). If no filter is provided, then the check will apply to all components.

You can see how to create a check from our Getting Started with Rubrics documentation.