Getting Started with Checks

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

With OpsLevel checks, you can verify that services:

• Are using a particular version of a library or framework
• Have migrated to a new third party tool (e.g., are all of our services 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 service been signed off by the architecture review board?).

Checks can be:

• Added to your rubric and evaluated to determine the maturity of your services. 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 services are progressing with implementing those changes.

Here is an example of a rubric containing 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 services and contribute to the levels of those services.

Disabled checks are not visible in the servicess 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 services’ Maturity Report tab but do not affect the levels of services until they are enabled. Service 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 service owners know who to contact for questions about a check on their service. As a check owner, you can provide notes to offer service owners additional details that might be important about that specific check.

Checks can apply to all or only a subset of services

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

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