Blog News Enable SLO-as-Code with Nobl9 and GitLab
May 9, 2022
4 min read

Enable SLO-as-Code with Nobl9 and GitLab

Learn how to take advantage of a streamlined SLO process and maintain a single source of truth for SLO definitions within your DevOps platform.


Nobl9 recently integrated with GitLab's CI to enable a consistent mechanism to publish Service Level Objectives (SLO) definitions from GitLab to Nobl9. With this SLO-as-Code integration, DevOps teams can take action when their error budgets are burning too fast or are about to be exhausted.

In today’s systems, 100% uptime isn’t realistic given the complex architectures and dependencies involved. SLOs enable you to define targets and have an error budget for tracking what's “good enough.” For example, you can target uptime of 99.9%, 99%, or even 95% because what truly matters is how much downtime or errors are acceptable before there is real customer impact.

Typically when organizations think about SLO-as-Code, they must use separate products to ensure their SLO definitions are always in sync with whatever tool they are using. This usually includes running command-line tools manually or building custom integrations within their code repositories.

With this CI configuration, every time you build your repo, GitLab will call sloctl, our command-line tool, and push the SLO definition to Nobl9. Customers can continue using GitLab to version their SLO definitions and keep their SLOs consistent. This ensures your SLO definition will always be up to date with what’s in Nobl9 and removes any discrepancies over what the latest SLO definition actually is. SREs, engineers, and anyone using the SLOs can still debate what the targets need to be, but there will always be a definitive source of truth in your code repository on what the current definition is.

Getting started

To set this up in GitLab, follow these steps:

1. Select Settings -> CI/CD, and click the Expand button next to Variables.


2. Add the following variables:






Note: If you haven’t done so already, you’ll need to install sloctl. You can install the executable on your local machine by following the instructions in the user guide. Once sloctl is installed, you can run the following command to retrieve your CLIENT_ID, CLIENT_SECRET, and ACCESS_TOKEN:

cat ~/.config/nobl9/config.toml

The PROJECT value is the name of the project inside Nobl9 that your SLO belongs 

The SLOCTL_YML value is the Nobl9 YAML file you want to push to Nobl9 on each 


3. Create the CI/CD job to apply the YAML, by going to CI/CD -> Jobs and clicking “Create CI/CD configuration file”.


Enter the following code in the file:








      - project: 'nobl9/nobl9-ci-template'

        ref: main

        file: '/nobl9.gitlab-ci.yml'

4. Kick off a build. Any changes to the SLOCTL_YML file that you reference will now automatically be pushed to Nobl9 once the updates are committed.

By partnering with GitLab and providing a convenient CI script and a command-line tool for managing SLOs, Nobl9 has truly enabled SLO-as-Code. We encourage existing Nobl9 customers who use GitLab to give it a try.

If you haven’t experienced Nobl9 yet, you can sign up for a free 30-day trial at to see all that it has to offer.

Quan To is Senior Director of Product Management, Jeremy Cooper is Senior Solutions Engineer, and Ian Bartholomew is SRE Manager at Nobl9.

Cover image by Vardan Papikayan on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert