Configuration: Service Levels: Objectives

Updated

Configuration: Service Levels: Objectives

Overview

Use this page to create and manage Service Level Objectives (SLOs). An SLO is a measurable reliability target, such as 99.9% availability or a maximum response-time threshold, that the platform evaluates continuously against live telemetry from your monitoring, uptime, or load-testing datasources.

SLOs sit inside the Service Levels module. Before you can create an objective, you need at least one configured datasource (set up on Configuration: Datasources) and, depending on the SLO type, one or more uptime checks (Uptime Monitoring: Checks), monitoring profiles (End-to-End Monitoring: Profiles), or load-testing data. Once saved, SLOs are consumed by the Service Levels: Dashboard, Service Levels: Health, and Service Levels: Violations pages, which evaluate compliance and raise alerts when targets are breached.

This page lists every SLO in a table showing its name, type, source, and target. From here you can create new objectives, edit existing ones, review their full version history, and delete objectives you no longer need.

Key concepts

  • Service Level Objective (SLO) - A named, versioned reliability target expressed as a percentage threshold (availability or latency) measured over a rolling time window. The platform compares live data against the target and records compliance. (related: Consumed by Service Levels: Dashboard and Service Levels: Violations for compliance reporting.)
  • Immutable version - Every time you save changes to an existing SLO, the platform creates a new numbered version rather than overwriting the previous one. Past versions are preserved and can be inspected via the Version history action. (related: Accessible through the Version history row action on this page.)
  • Window - The rolling time range (in days) over which the platform aggregates measurements to calculate whether the SLO target is met. Longer windows smooth short-lived spikes; shorter windows surface recent degradation faster. (related: Configured in the Window days field when creating or editing an objective.)
  • Bucket size - The granularity, in minutes, at which raw telemetry is grouped before being evaluated against the SLO. Smaller buckets increase resolution but raise storage and compute overhead. (related: Configured alongside Window days in the objective form.)

When to use it

  • You are formalising a reliability commitment (SLA or internal target) and need the platform to track compliance automatically.
  • You want to see SLO burn-down and violation history on Service Levels: Health or Service Levels: Violations.
  • An existing SLO target has changed (for example, a new contractual threshold) and you need to record the change with an audit reason while preserving the old version.
  • You need to inspect the history of threshold changes for a specific objective.
  • You are removing an SLO that no longer applies and want to clean up the objectives list.

Before you begin

  • At least one datasource must be configured on Configuration: Datasources so the objective has a source to evaluate against.
  • For uptime-backed SLOs, one or more uptime checks must exist on Uptime Monitoring: Checks so their GUIDs can be referenced in the Uptime check ids field.
  • For monitoring-backed SLOs, a monitoring profile must exist on End-to-End Monitoring: Profiles so its profile ID can be referenced in the Profile id field.
  • Your account must have configuration-level write access; read-only accounts can view the list but cannot create, edit, or delete objectives.

Common workflows

Create a new Service Level Objective

Persona: Load-test operator or administrator

1. Select New objective in the toolbar.

- Expect: The objective creation form opens, showing fields for Objective name, Type, Source type, Target %, and additional fields depending on the type selected.

2. Type a descriptive name in Objective name (for example, 'API Availability').

- Expect: The name field is populated; it will appear in the OBJECTIVE column of the table after saving.

3. Choose a value from Type to select the reliability category you want to measure.

- Expect: Additional fields relevant to that type (such as Threshold ms for latency or Max error % for error rate) become visible.

4. Choose a value from Source type to select the data pipeline that will feed this SLO.

- Expect: Source-specific fields (such as Uptime check ids, Profile id, or Measurement name) appear.

5. Enter a value in Target % (for example, 99.9) and configure Window type, Window days, and Bucket size (minutes).

- Expect: All numeric fields are populated.

6. Optionally enter a note in Change reason explaining why this SLO is being created, then select Save.

- Expect: The form closes and a new row appears in the objectives table showing the SLO name, type, source, and target.

Verify: The new SLO appears as a row in the objectives table. Open Version history on the row to confirm version 1 is recorded.

Edit an existing objective and record a change reason

Persona: Administrator updating a contractual threshold

1. Locate the objective in the table and select the Edit objective icon in its ACTIONS cell.

- Expect: The objective form opens pre-populated with the current values.

2. Update the relevant fields (for example, change Target % from 99.9 to 99.95).

- Expect: The field reflects the new value.

3. Enter a short description in Change reason (for example, 'Raised target to 99.95% for the Q3 SLA'), then select Save.

- Expect: The form closes; the table row shows the updated target value.

Verify: Select Version history on the same row. The list should show at least two versions; the latest version should reflect the new target and display the change reason you entered.

Steps

Step 1

Navigate to Configuration: Service Levels: Objectives using the platform navigation.

Expected result: The Objectives page loads showing the SLO list table with columns OBJECTIVE, TYPE, SOURCE, TARGET, and ACTIONS. Until objectives have been created, the table body shows 'No objectives configured yet.'

This is the starting point for all SLO management tasks on this page.

  • The subtitle 'SLO definitions. Editing creates a new immutable version.' appears directly below the page heading and signals that any future edit will preserve the old version rather than overwrite it.
  • The Refresh and New objective buttons are visible in the toolbar at the top right.
  • The ACTIONS column is present but contains no icon buttons until at least one objective row exists.

Configuration: Service Levels: Objectives - step 1

Field reference

| Field | Purpose | Format / Validation | Required | Default |

|---|---|---|---|---|

| Objective name | The human-readable label for this SLO, displayed in the objectives table and referenced on the Service Levels Dashboard and Violations pages. Choose a name that identifies the service and the measured quality attribute (for example, 'API Availability'). | Free text string | Yes | - |

| Type | Selects the category of reliability being measured. The chosen type determines which additional fields are shown (for example, latency types expose Threshold ms; availability types expose Max error %). | Enumerated selection | No | - |

| Source type | Specifies which data pipeline feeds this SLO: monitoring checks, uptime checks, load-testing runs, or a raw metric. Choosing the right source type ensures the platform reads from the telemetry stream that actually reflects the target service. | Enumerated selection | No | - |

| Target % | The percentage threshold the SLO must meet or exceed (for availability) or stay within (for error rate). Setting 99.9 means the service must be available 99.9% of the time over the configured window. Higher values leave less error budget; lower values tolerate more downtime. | Decimal number | No | - |

| Threshold ms | For latency-type SLOs, the maximum acceptable response time in milliseconds. Requests that exceed this value count as failures against the SLO. A lower threshold is stricter; a higher threshold tolerates slower responses. | Integer (milliseconds) | No | - |

| Max error % | The maximum tolerable error-rate percentage before the SLO is considered breached. Lower values enforce stricter reliability; higher values permit more failures before a violation is raised. | Decimal number | No | - |

| Window type | Controls whether the evaluation window is rolling (continuous, always covering the last N days) or calendar-aligned (resets at the start of each period). Rolling windows give a continuously updated view; calendar windows align with billing or reporting cycles. | Enumerated selection | No | - |

| Window days | The number of days in the evaluation window. Longer windows (for example, 30 days) smooth transient spikes and represent monthly SLAs; shorter windows (for example, 7 days) surface recent degradation more quickly. | Integer (days) | No | - |

| Bucket size (minutes) | The granularity at which telemetry is aggregated before evaluation. Smaller buckets (for example, 1 minute) increase measurement resolution and catch brief outages; larger buckets reduce storage overhead but may miss short spikes. | Integer (minutes) | No | - |

| Measurement name | The metric key or measurement identifier the platform queries from the selected datasource. Must match the exact metric name stored in the datasource (for example, 'httprequeststotal'). | Free text string | No | - |

| Uptime check ids | One or more GUID identifiers of uptime checks (created on Uptime Monitoring: Checks) whose results feed this SLO. Provide multiple GUIDs when the SLO should aggregate across several check points. | Comma-, space-, or newline-separated GUIDs | No | - |

| Profile id | The unique identifier of the End-to-End Monitoring profile (from End-to-End Monitoring: Profiles) whose run results this SLO evaluates. | GUID or numeric ID | No | - |

| Profile name | Display name associated with the selected monitoring profile. Shown for confirmation; typically populated automatically when a Profile id is entered. | Free text string (read-assist) | No | - |

| Monitoring datasource | The datasource configured on Configuration: Datasources from which monitoring telemetry is read for this SLO. Select the datasource that holds the relevant monitoring metrics. | Enumerated selection | No | - |

| LoadTesting datasource | The datasource from which load-test result data is read when the SLO source type is load-testing. Select the datasource that stores results from your load test runs. | Enumerated selection | No | - |

| Metadata | Optional free-form key-value pairs attached to this SLO for filtering, integration, or audit purposes. Use the format 'key=value; key2=value2'. | Semicolon-separated key=value pairs | No | - |

| Change reason | A short description of why this version of the SLO was created (for example, explaining a target change). This text is stored with the immutable version record and is visible in Version history, providing an audit trail. | Free text string | No | - |

| NoData counts as failure | When enabled, periods during which the datasource returns no data are treated as SLO failures rather than being ignored. Enable this if a silent datasource should not silently pass the SLO; disable it if telemetry gaps (for example, maintenance windows) should not penalise the score. | Boolean toggle | No | - |

Column reference

| Column | What it shows | How to read it |

|---|---|---|

| OBJECTIVE | - | The name assigned to the SLO when it was created. |

| TYPE | - | The reliability category of this SLO (for example, availability or latency). |

| SOURCE | - | The data source type feeding this SLO, reflecting the Source type chosen during creation. |

| TARGET | - | The numeric threshold value (percentage or milliseconds) the SLO must meet. |

| ACTIONS | - | Per-row action buttons: Version history (view all saved versions), Edit (open the objective form), and Delete (permanently remove the objective). |

Controls reference

Refresh

Reloads the objectives table from the server to show any SLOs added or changed by other users since the page was last loaded.

When to use: When you suspect the list is stale or after another team member reports creating an objective that is not yet visible.

Side effects: Read-only: no data is modified; the table is replaced with the current server state.

New objective

Opens the objective creation form, allowing you to define the name, type, source, target, window, and other parameters for a new SLO.

When to use: When you need to add an SLO that does not yet exist in the list.

Side effects: Mutating: submitting the form creates a new SLO record (version 1) and adds a row to the table.

Version history

Opens the version history panel for the selected objective, listing every immutable version that has been saved along with its change reason and timestamp.

When to use: When you need to audit past threshold changes or roll back understanding of what a target was at a specific point in time.

Side effects: Read-only: no data is modified.

Edit objective

Opens the objective form pre-populated with the current values of the selected SLO so you can modify any field.

When to use: When a target threshold, window, or source needs to change. Saving creates a new immutable version rather than overwriting the current one.

Side effects: Mutating: saving the form increments the version counter and stores the previous values as a historical version.

Delete objective

Displays a confirmation dialog warning that the objective's versions and snapshots will also be affected, then permanently removes the SLO if confirmed.

When to use: When an SLO is obsolete and you want to remove it from the list and stop the platform from evaluating it.

Side effects: Mutating and irreversible: the objective and its version history are deleted. The confirmation dialog text reads: "Delete objective '[NAME]'? Its versions and snapshots may be affected. This cannot be undone."

Save

Submits the create or edit form, persisting the objective to the platform. On edit, a new immutable version is created.

When to use: After filling in all required fields when creating or editing an objective.

Side effects: Mutating: creates or updates the SLO record; the new row (or updated values) appears in the table.

Cancel

Closes the create or edit form without saving any changes.

When to use: When you opened the form by mistake or decide not to proceed with the change.

Side effects: Read-only: no data is modified; the form is dismissed.

Verify the result

After creating an objective, its row appears immediately in the table with the correct name in the OBJECTIVE column, the chosen type in TYPE, the data source in SOURCE, and the numeric threshold in TARGET. Select Version history on the row to confirm that version 1 is recorded with the timestamp and (if entered) the change reason. If the row does not appear, select Refresh to reload the table from the server. If the Save button remains inactive (spinning), wait for the busy indicator to clear; if it stays blocked, check that all required fields, particularly Objective name, are filled in.

Troubleshooting

  • Symptom: The table shows 'No objectives configured yet.' after you expect rows to exist. Fix: Select Refresh in the toolbar to reload the list; another user may have created objectives since the page was last loaded.
  • Symptom: The Save button does not respond when you select it. Fix: Check that Objective name is filled in: it is the only required field and the form will not submit without it.
  • Symptom: Source-specific fields such as Uptime check ids or Profile id are not visible in the creation form. Fix: Confirm that you have selected the correct Source type for your scenario; these fields only appear for the matching source type.
  • Symptom: You cannot find a monitoring profile ID to enter in Profile id. Fix: Open End-to-End Monitoring: Profiles in a separate tab to locate the profile and copy its identifier.
  • Symptom: After editing an objective, the target value in the table still shows the old number. Fix: Select Refresh to force a reload; if the value still does not update, re-open the edit form to verify the change was saved.
  • Symptom: You deleted an objective but its SLO data still appears on the Service Levels Dashboard. Fix: Deletion removes the objective definition but existing snapshots may persist briefly; reload the dashboard after a short interval or check Configuration: Service Levels: Storage for retention settings.

Related articles

Was this article helpful?
0 out of 0 found this helpful