The OpenSLO project has been steadily gaining traction across the reliability engineering world, and for good reason. As a community-driven, vendor-neutral specification for defining Service Level Objectives (SLOs) in YAML, OpenSLO is reshaping how teams approach reliability as code. Since its launch, contributors across the ecosystem, including Nobl9, have helped shape its growth, evolving it into a key open-source building block for SLO-based tooling.
At Nobl9, we’ve supported OpenSLO from the beginning. Many of our own declarative tools mirror the same principles that drive OpenSLO. So it was only natural that we’d make it easier to bring OpenSLO configurations into the Nobl9 platform.
We at Nobl9 love being engaged with our community. We're active contributors to open source and long-time supporters of standards that help reliability teams work smarter.
We maintain a number of projects that reflect our commitment to the community, including:
We also released a general-use validation library for Go, called govy, which is the backbone of validation in our system and also used by the OpenSLO Go SDK. Read more about govy here.
While Nobl9 and OpenSLO both use YAML to define SLOs, the schemas aren’t directly compatible. Nobl9 builds on the foundation of OpenSLO with more advanced capabilities, including composite SLOs, anomaly detection, data replay, custom SLI analysis, advanced alerting, and integrations with popular data sources.
If OpenSLO is the shared specification, Nobl9 is the complete platform that helps teams operationalize those standards at scale.
Here’s a sample SLO definition using OpenSLO.
The equivalent YAML written for Nobl9 to illustrate how the structure and schema differ.
In order to allow Nobl9 users to use their OpenSLO reliability configuration in the Nobl9 platform, we’ve introduced a dedicated library which utilizes OpenSLO and Nobl9 SDKs.
Starting with sloctl version 0.12.0 the conversion can be easily executed with sloctl convert openslo command.
The conversion supports the only stable OpenSLO version, which as of writing this article is v1. In addition, only one way conversion is implemented, from OpenSLO to Nobl9 format.
When an OpenSLO field doesn’t have a direct counterpart in Nobl9, such as metadata.project, the converter applies defaults when possible. For cases where customization is needed, users can include specific values via metadata.annotations using the nobl9.com/ prefix.
This snippet shows how annotations can be used to map values precisely.
Some structural elements also differ. For instance, OpenSLO’s v1.SLI is a standalone object, while Nobl9 embeds it directly within the SLO definition. The converter automatically restructures these differences by inlining or extracting objects as needed.
This example demonstrates both directions clearly.
To dig deeper into how the converter works and how schema differences are addressed, check out the converter README.
For additional context on SLOs as code, visit our documentation or explore more at openslo.com.