SLO management

Reading time: 0 minute(s) (0 words)

Once created, your SLOs aren't static. Effective SLO management is a continuous process of refining and reorganizing objectives to align with evolving services and SRE best practices. You may need to edit an SLO if it has any data anomalies, requires update upon review, or is shown on the SLO oversight dashboard for any other reason implicating it can be improved.

This guide details the fundamental operations for managing existing SLOs, covering how to edit, copy, and move them to update configurations, repurpose them for new services, and maintain your organizational structure.

Edit SLO

You can edit SLOs in the following ways:

• In the Nobl9 web application
• By modifying its YAML definition

To edit an SLO in the Nobl9 web application, go to your required SLO details page and do one of the following:

• Click (edit) to open the SLO wizard

Opening SLO wizard

• Click (more actions) > View YAML to open the code editor.
  Make your changes, ensuring they follow the Nobl9 requirements for YAML definitions

View YAML

When editing an SLO, be aware that changing certain fields can have a significant impact. Editing budget-critical fields resets calculations for the existing SLO, while other field modifications have no impact on calculations and charts.

After every update, Nobl9 automatically generates an annotation of the User type SLO edit category. These annotations contain the following information:

• Created by—the user who made the change, and the time of the edit
• Budget impact describes the modification's impact on the SLO's error budget. Changing budget-sensitive fields resets SLO calculations
• Change origin—the source of the change, such as web browser, Nobl9 Terraform provider, sloctl, or Nobl9 SDK for Go
• Version comparison—a YAML diff showing the changes. The previous version is highlighted in red, the current in green, and the unchanged configuration in gray

Annotation added after the SLO was edited

When you modify budget-critical SLO settings, historical data for the SLO is erased, the error budget is reset, and calculations start over from the moment the change is saved. The budget-critical fields are as follows:

• Time window: duration and type
• Error budget calculation method
• Target
• Time slice allowance target (for the time slices budgeting method)
• Values: operator and value

Budget-critical SLO fields

Changes to other fields will not impact calculations. These include, but are not limited to, the following settings:

• Query
• Display name and description
• Alert policies and data anomaly detection settings
• Attachments and labels
• Composite-specific settings:
  • Max delay, when delayed, components

SLO name, project, service, and incremental settings

• Editing an SLO's name or project does not modify the existing SLO. Instead, applying these changes creates a new SLO that begins collecting data from the moment it is created.
• Editing the service moves the SLO to the new service, retaining all historical data, calculations, and charts.
• The incremental setting cannot be edited directly. To change it, you must replace the objective with a new one.

The following table summarizes the impact of field modifications on SLO calculations.

Field name	Impact	YAML field
Time window settings	Resets calculations	timeWindows
Error budget calculation method		budgetingMethod
Target		target
Time slice allowance in time slices		timeSliceTarget
Values operator and value		value and op
Objective name Only auto-generated	Resets calculations and charts	name

Copy SLO

You can copy SLOs in the Nobl9 web application. For this:

1. Go to your required SLO details.
2. Click (more actions).
3. Select Copy SLO.

Copy SLO

4. Make the necessary amendments:
   • Modify the name for your copy.
   • Select the target project and service.
5. Click Copy SLO. The copied SLO will appear under the project and service you specified, and you will be the owner of the copy.

Key takeaways

• You can copy an SLO to another service within the same project.
• When you copy an SLO with attached alert policies to another project, the copy will not retain the alert policies from the original SLO.
• If the original SLO is configured with anomaly notifications, your copy will only retain alert methods from projects you can access. Alert methods from projects you cannot access will be unlinked.

Original SLO settings	Settings retention	Notes
Data source	Always retained	Data collection mirrors the source SLO.
Replay settings
Metric settings and query
Error budget calculation settings
Labels, links, descriptions
Collected data	Never retained	A copied SLO starts collecting data anew.
SLO name		A new name is generated for the SLO copy.
Alert policies	Can be retained	Alert policies are retained if the SLO is copied within the same project; otherwise, they are unlinked.
No data anomaly alert methods		Alert methods from projects you can access are retained. All other alert methods are unlinked.

SLO settings retention table

Move SLO

You can move SLOs between projects in the Nobl9 web application. Moving an SLO retains its collected data along with calculations and charts. To move an SLO:

1. Go to your required SLO details.
2. Click (more actions).
3. Select Move SLO.

Move SLO

4. Select the target project and service.
5. Click View summary to proceed.
6. Click Move SLO to confirm.

Key takeaways

• You can create a project and service when moving an SLO. For this, start typing the required names. Use only lowercase characters, numbers, and dashes.
• Moving an SLO updates its link. If the SLO was part of reports filtered by its link, consider updating their filters. If you shared this SLO, the previous link will no longer work.
• If other users need to access this SLO, they may lose their permissions after it is moved. Ensure the that the necessary users have the required permissions in the target project.
• If the SLO has alert policies attached, they will be unlinked when the SLO is moved to another project.
• If this SLO is a component of a composite SLO, its project in the composite structure will be updated automatically.

Source SLO settings	Settings retention	Notes
Data source	Always retained	The SLO's core settings do not change after being moved. Collected data, calculations, and charts are retained.
Replay settings
Metric settings and query
Error budget calculation settings
Collected data
SLO name
No data anomaly alert methods
Labels, links, descriptions
Alert policies	Never retained	SLOs can only be moved between projects. Alert policies are unlinked after the SLO is moved.
User permissions		Access permissions are not transferred. You may need to grant permissions to users in the new project.

SLO settings retention table

Useful links

Check out these related guides and references:

Service Level ObjectivesService Level ObjectivesSLO inputs and outputsGetting started with Nobl9Use case of SLO configurationUse casesCalendar-aligned time windowsSLO guidesRolling time windowsSLO guidesOccurrences budgeting methodSLO guidesTime slices budgeting methodSLO guidesIncreasing SLO sensitivity to incidentsSLO guidesComposite SLOsCompositesSLO annotationsNobl9 featuresError budgetGlossaryAlertingAlerting