SLO management
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. 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

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

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.
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

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 anomaly alerting settings
- Attachments and labels
- Composite-specific settings:
- Max delay, when delayed, components
- Editing an SLO's
name
orproject
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:
- Go to your required SLO details.
- Click
(more actions).
- Select Copy SLO.

- Make the necessary amendments:
- Modify the name for your copy.
- Select the target project and service.
- 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. |
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:
- Go to your required SLO details.
- Click
(more actions).
- Select Move SLO.

- Select the target project and service.
- Click View summary to proceed.
- 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. |