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. Checks are placed on your rubric and they are used to generate your services’ levels.
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?).
Here is an example of a rubric containing checks.
There are a few options that are shared between all checks types.
Enabled / Disabled Enabled checks are applied against matching services and contribute to the levels of those services. Disabled checks do not affect the levels of your services, but you can still view individual reports for disabled checks.
Checks have 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.
You can see how to create a check from our Getting Started with Rubrics documentation.