Skip to main content

YAML guide

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

This document explains how Nobl9 configurations are represented in the sloctl API, and how you can express them in .yaml format.

Overall schema

High-level YAML schema for Nobl9
apiVersion: n9/v1alpha
kind: Agent | Annotation | AlertMethod | AlertPolicy | AlertSilence |
DataExport | Project | RoleBinding | Service | SLO |
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Optional
labels: # Map, optional
"key_1": # Label's key
- "value_1" # Label's value
spec:
...

Notes on the overall schema:

FieldTypeDescription
metadata.name
mandatory
stringField following DNS RFC1123 conventions. Constraints:
• Max. 63 characters.
• Only lowercase alphanumeric characters or hyphens.
• Must start and end with an alphanumeric character.
metadata.project
mandatory
stringField following DNS RFC1123 conventions. Constraints:
• Max. 63 characters.
• Only lowercase alphanumeric characters or hyphens.
• Must start and end with an alphanumeric character.
metadata.displayName
optional
stringCan contain max 63 characters. There's no additional validation.
metadata.labels
optional
mapLabels are key-value pairs that can be attached to SLOs, services, projects, and alert policies. Constraints:
• Labels must be in the key: value format (key=value in sloctl).
key can contain only lowercase alphanumeric characters, underscores, and dashes; must start with a letter and end with an alphanumeric character; maximum length 63 characters.
value can contain Unicode characters; maximum length 200 characters.
uniqueness of names

All names must be unique in the scope of one project.

It is not possible to have two objects of the same kind with exactly the same name in a given project.

adding labels

When adding labels to a YAML definition, remember to put both key and value in parentheses (""), for example:

labels:
"team":
- "green"

Otherwise, sloctl may return the following error:

Error: malformed JSON payload - pass single list of valid JSON objects.

Overview of available YAML objects

The following sections describe the types of objects that are available in Nobl9 and how to configure them.

Agent

The agent is middleware between the Nobl9 app and an external data source. It gathers metrics data and sends it to Nobl9. Agents need to be installed on the customer's server.

Refer to Sources for details about configuring the agent for each data source via sloctl.

General sample for kind: Agent
apiVersion: n9/v1alpha  # Mandatory
kind: Agent # Mandatory
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Mandatory
spec:
description: string # Optional
sourceOf:
- Metrics
- Services
releaseChannel: beta # Mandatory, enum
queryDelay:
unit: Second | Minute # Mandatory, enum
value: numeric # Mandatory
datadog:
...
# historicalDataRetrieval is an optional structure related to Replay
# Use only with sources that support it
# Otherwise, sloctl will return a validation error
historicalDataRetrieval:
maxDuration:
value: 0 # Optional, numeric
unit: Minute | Hour | Day # Optional, enum
defaultDuration:
value: 0 # Optional, numeric
unit: Minute | Hour | Day # Optional, enum

Notes on fields specific to Agent

FieldTypeDescription
queryDelay.unit
mandatory
enumSpecifies the unit for the query delay. Possible values: Second | Minute.
• Check query delay documentation for default unit of query delay for each source.
queryDelay.value
mandatory
numericSpecifies the value for the query delay.
• Must be a number less than 1440 minutes (24 hours).
• Check query delay documentation for default values of query delay for each source.
releaseChannel
mandatory
stringSpecifies the release channel.
• Must be one of: beta | stable.
• See release channels for more details.
historicalDataRetrieval
optional
n/aOptional structure related to Replay.
Use only with supported sources.
• If omitted, Nobl9 uses the default values of value: 0 unit: Day for maxDuration and defaultValutaion
maxDuration.value
optional
integerSpecifies the maximum duration for historical data retrieval. Must be integer ≥ 0. See Replay documentation for values of max duration per data source.
maxDuration.unit
optional
enumSpecifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day.
defaultDuration.value
optional
integerSpecifies the default duration for historical data retrieval. Must be integer ≥ 0 and value.maxDuration.
defaultDuration.unit
optional
enumSpecifies the unit for the default duration of historical data retrieval. Accepted values: Minute | Hour | Day.

If you describe infrastructure as code, you might also consider creating agents via Terraform. You can find more details in our Terraform documentation.

AlertMethod

When an alert is triggered, you can send a notification to an external tool or a REST endpoint (a web service). Alert methods can be associated with all available integrations.

General sample for kind: AlertMethods
apiVersion: n9/v1alpha  # Mandatory
kind: AlertMethod # Mandatory
metadata:
name: string # Mandatory
displayName: string # Optional
spec:
description: string # Optional
# Only one of the following is possible per one AlertMethod definition
# Refer to alert methods documentation to see detailed specifications
discord:
...
# Or
email:
...
# Or
jira:
...
# Or
msteams:
...
# Or
opsgenie:
...
# Or
pagerDuty:
...
# Or
servicenow:
...
# Or
slack:
...
# Or
webhook:
...

If you describe infrastructure as code, you might also consider defining the alert methods with the same convention. You can find more details in our Terraform documentation.

AlertPolicy

Alert policies define when to trigger an alert via the configured alert method. A Nobl9 AlertPolicy accepts up to three conditions. All defined conditions must be met to trigger an alert.

caution

In Nobl9 release 1.66.2-3, the previous response from sloctl get alertpolicies is deprecated, and will be phased out in the future.

In subsequent updates, the command will return only the metadata.name and metadata.project fields associated with the alert policy (instead of returning the entire block for the alertMethods object):

apiVersion: n9/v1alpha
kind: AlertPolicy
metadata:
...
spec:
...
alertMethods:
- metadata:
name: my-alert-method
project: my-project

We'll inform you about the full phase-out in a separate announcement.

General sample for kind: AlertPolicy
apiVersion: n9/v1alpha  # Mandatory
kind: AlertPolicy # Mandatory
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Optional, if not defined, Nobl9 returns a default value for this field
spec:
description: string # Optional
severity: Low | Medium | High # Mandatory, enum
cooldown: "5m" # Mandatory, valid string duration, accepted units: s, m, h
conditions:
- measurement: timeToBurnBudget | timeToBurnEntireBudget | averageBurnRate | burnedBudget # Mandatory, enum
value: string or numeric # Mandatory
op: lt | gt | lte | gte # Mandatory, enum
lastsFor: "0m" # Optional, valid string duration. Default 0 (seconds | minutes | hours)
alertMethods: # You can append several alertMethods
- metadata:
name: string # Mandatory, name of the alert method
project: string # Optional, define if you want to use an AlertMethod from a different project than that defined for AlertPolicy
- metadata:
name: string # Mandatory, name of the alert method
project: string # Optional, define if you want to use an AlertMethod from a different project than that defined for AlertPolicy

Notes on fields specific to AlertPolicy:

FieldTypeDescription
spec.cooldown
mandatory
stringDuration representing the time measured since the last time point when all conditions were satisfied. Constraints:
• Default value: 5m.
• Accepted units: Seconds | Minutes | Hours. Examples: 5m, 1h, 30s.
• The minimum allowable value is 5m, with no upper limit.
• Must adhere to a valid time string duration format, see parse duration for more details.
conditions[n].measurement
mandatory
stringMeasurement options for the condition:

timeToBurnBudget When the remaining error budget will be exhausted. The expected value is a string in time duration format; for example, 72h (3 days).

    Example in human-readable format: The remaining error budget will be exhausted in 3 days.

timeToBurnEntireBudget When the entire error budget will be exhausted. The expected value is a string in time duration format; for example, 72h (3 days).

    Example in human-readable format: The entire error budget will be exhausted in 3 days.
averageBurnRate - how fast the error budget is burning

    Example in human-readable format: Error budget burn rate is 1.1x.

burnedBudget how much error budget has already been burnt. This contrasts with the UI, where the error budget is expressed in terms of the remaining amount. Each option corresponds to a specific measurement value and format.

    Example in human-readable format: Error budget is above 97%.

    The same example in the UI is represented as Error budget remaining 3%.
conditions[n].lastsFor
optional
stringOptional field indicating how long a given condition needs to be valid to mark the condition as true.
• Default: 0 (seconds)
• Accepted units: Seconds | Minutes | Hours
• Examples: 5m, 1h, 30s
conditions[n].op
mandatory*
enum* Mandatory for rawMetrics only.
A mathematical inequality operator; possible values are:
lte - less than or equal to ()
gte - greater than or equal to (), lt - less than (<)
gt - greater than (>).

The operator depends on the measurement type:
• For timeToBurnBudget op=lt
• For averageBurnRate op=gte
• For burnedBudget op=gte.
caution

Cooldown on the spec.conditions[] level is allowed but deprecated:

  • If you define cooldown on the spec.conditions[] level, the maximum value from all conditions is saved.

  • If you define cooldown on both the kind: AlertPolicy and spec.conditions[] levels, Nobl9 will return a validation error.

If you describe infrastructure as code, you can also define the alert policy with the same convention. You can find more details in our Terraform documentation.

AlertSilence

AlertSilence allows you to turn off alerts that are attached to an SLO for a defined period of time. For more details, see Silencing alerts.

General YAML for kind: AlertSilence
apiVersion: n9/v1alpha
kind: AlertSilence
metadata:
name: alert-silence-name
project: default
spec:
description: AlertSilence description
slo: slo-name # the name of the SLO AlertSilence will be applied to
alertPolicy:
name: alert-policy-name # the name of the AlertPolicy AlertSilence will be applied to
period: # define period for the AlertSilence
startTime: 2025-01-01T12:00:00+02:00 # define the start date-time point where the Alerts will be silenced
endTime: 2025-01-01T13:00:00+02:00 # define the start date-time point where the Alerts will be silenced
duration: 1h # Mandatory, valid string duration

Notes on fields specific to AlertSilence

FieldTypeDescription
spec.alertPolicy
mandatory
stringalertPolicy that AlertSilence will be applied to. spec.alertPolicy must be in the same project as AlertSilence and SLO.
spec.period.startTime
mandatory
stringDefines the date-time point where the alerts will be silenced. Must be in YYYY-MM-DDTh:mm:ssZ format (ISO8601).
spec.period.endTime
mandatory
stringDefines the date-time point where the alerts will be silenced. Must be in YYYY-MM-DDTh:mm:ssZ format (ISO8601).
spec.period.duration
mandatory
stringDefines the duration for which alerts will be silenced from the applying time. Accepted units: s | m | h.

Annotation

The SLO annotations service lets Nobl9 users add notes to their metrics. For more details, refer to SLO annotations.

General YAML for kind: Annotation
apiVersion: n9/v1alpha
kind: Annotation
metadata:
name: string # Mandatory
project: string # Mandatory, the name of the project the annoation is attached to
spec:
slo: string # Annotation's objective
description: string # Optional
objectiveName: string # Optional, must refer to existing SLO Objective
startTime: YYYY-MM-DDTh:mm:ssZ # Mandatory, defined start date-time point
endTime: YYYY-MM-DDTh:mm:ssZ # Mandatory, defined end date-time point

Notes on fields specific to Annotations:

FieldTypeDescription
metadata.name
mandatory
stringA unique annotation name, required for distinguishing project annotations.
spec.slo
mandatory
stringThe name of the SLO the annotation applies to.
spec.description
optional
stringA string (plain text) describing the annotation. The maximum number of characters is 1000.
spec.startTime
mandatory
stringDefines the date-time point where the annotation will be placed in the graph. The value must be in the YYYY-MM-DDTh:mm:ssZ format that complies with ISO8601. If startTime == endTime, the annotation will be placed at a single time point.
spec.endTime
mandatory
stringDefines the date-time point where the annotation will be placed in the graph. The value must be in the YYYY-MM-DDTh:mm:ssZ format that complies with ISO8601. If startTime == endTime, the annotation will be placed at a single time point.
spec.objectiveName
optional
stringOptional field allowing you to add an annotation to a particular, already existing SLO objective. If not specified, the annotation is attached to the SLO.

DataExport

Apply the following YAML to create the configuration to export your data from Nobl9. For more details, see the Data export documentation.

note

DataExport is a premium feature. Contact your Nobl9 sales representative to activate it.

General YAML for kind: DataExport
apiVersion: n9/v1alpha
kind: DataExport
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Optional
spec:
exportType: S3 | GCS # Mandatory, enum
spec:
bucketName: string # Mandatory
roleArn: string # Mandatory

Notes on fields specific to DataExport:

FieldTypeDescription
spec.exportType
mandatory
enumDefine where you want to export your data to: S3 or GCS.
spec.bucketName
mandatory
stringThe name of the S3 or GCS bucket.
spec.roleArn
mandatory*
string* Mandatory for S3 and Snowflake export types.
This is the Amazon Resource Name (ARN) of the role that the Nobl9 agent is assuming to upload files.

Direct

Direct configuration gathers metrics data directly from the external source based on provided credentials. You don't need to install anything on your server side.

Check Sources for details about configuring the direct for each data source via sloctl.

General YAML for kind: Direct
apiVersion: n9/v1alpha
kind: Direct
metadata:
name: string # Mandatory
displayName: string # Optional
project: default # Mandatory, string
spec:
description: string # Optional
sourceOf:
- Metrics
- Services
# Only one type of source configuration is allowed for Direct, for example:
appDynamics:
...
releaseChannel: beta | stable # Mandatory, enum
queryDelay:
unit: Second | Minute # Mandatory, enum
value: numeric # Mandatory, must be a number less than 1440 minutes (24 hours)
logCollectionEnabled: false # Boolean, defaults to 'false'. Set to true if you'd like your source to collect logs. It's a beta functionality available only through direct release channel. Reach out to support@nobl9.com to activate it.
# historicalDataRetrieval is an optional structure related to Replay
# Use only with sources that support it
# Otherwise, sloctl will return a validation error
historicalDataRetrieval:
maxDuration:
value: numeric # Optional
unit: Minute | Hour | Day # Optional, enum
defaultDuration:
value: numeric # Optional
unit: Minute | Hour | Day # Optional, enum

Important notes on fields specific to Direct

FieldTypeDescription
queryDelay.unit
mandatory
enumSpecifies the unit for the query delay. Possible values: Second | Minute.
• Check query delay documentation for default unit of query delay for each source.
queryDelay.value
mandatory
numericSpecifies the value for the query delay.
• Must be a number less than 1440 minutes (24 hours).
• Check query delay documentation for default values of query delay for each source.
logCollectionEnabled
optional
booleanDefaults to false. Set to true if you'd like your source to collect event logs. Beta functionality available only through direct release channel. Reach out to support@nobl9.com to activate it.
historicalDataRetrieval
optional
n/aOptional structure related to configuration related to Replay.
❗ Use only with supported sources.
• If omitted, Nobl9 uses the default values of value: 0 and unit: Day for maxDuration and defaultValutaion
maxDuration.value
optional
integerSpecifies the maximum duration for historical data retrieval. Must be integer ≥ 0. See Replay documentation for values of max duration per data source.
maxDuration.unit
optional
enumSpecifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day.
defaultDuration.value
optional
integerSpecifies the default duration for historical data retrieval. Must be integer ≥ 0 and value.maxDuration.
defaultDuration.unit
optional
enumSpecifies the unit for the default duration of historical data retrieval. Accepted values: Minute | Hour | Day.
note

Be cautious with the authentication details you input into the direct YAML configuration. These details are encrypted and kept safe within Nobl9.

If you describe infrastructure as code, you might also define the alert policy with the same convention. You can find more details in our Terraform documentation.

Objective

Objectives are the thresholds for your SLOs. You can use objectives to define the tolerance levels for your metrics.

SLO objective Unique Identifier

An SLO objective unique identifier allows setting the same value for different SLIs within the same SLO. As such, Nobl9 is adding a name identifier to each SLO objective to ensure uniqueness in error budget calculations. For more detailed information, check SLO objective unique identifier.

General YAML for spec.objectives
apiVersion: n9/v1alpha
kind: SLO
metadata:
...
objectives:
- displayName: string # Optional
op: lte | gte | lt | gt # Mandatory, enum. An accepted comparative method for labeling an SLI, required for rawMetric only
value: numeric # Use withrawMetric only; all objectives of the SLO must have unique values
target: numeric [0.0, 1.0) # Mandatory, budget target for given objective of the SLO
timeSliceTarget: numeric (0.0, 1.0] # Required only when budgetingMethod is set to Timeslices
countMetrics:
# countMetrics {good, total} should be defined only if rawMetric is not set
# If rawMetric is defined on the SLO level, raw data received from metric source is compared with objective value
# countMetrics good and total must contain the same source type configuration
incremental: true | false # Enum, mandatory
good: # Mandatory, query for good occurrences
total: # Mandatory, query for total occurrences
- displayName: string # Optional
value: numeric # Use with rawMetrics and countMetrics with multiple objectives; value must unique for all objectives
target: numeric # Mandatory
op: lte | gte | lt | gt # Enum, required for rawMetric only
timeSliceTarget: numeric # Required only if the budgetingMethod is set to Timeslices
...

Notes on the objectives[] sequence array list:

FieldTypeDescription
objectives[n].value
mandatory*
numeric* Mandatory for rawMetrics and countMetrics with multiple objectives only.
The value field is used to compare values gathered from the metric source.
objectives[n].op
mandatory*
enum* Mandatory for rawMetrics only.
A mathematical inequality operator; possible values for this field are:
lte - less than or equal (≤)
gte - greater than or equal ()
lt - less than (<)
gt - greater than (>)
objectives[n].target
mandatory
numericThe budget target for the given objective of the SLO
• Accepted range: [0.0, 1.0)
objectives[n].timeSliceTarget
mandatory*
numeric* Mandatory only when budgetingMethod is set to Timeslices.
• Accepted range: (0.0, 1.0]
objectives[n].countMetrics
mandatory
metricRepresents the query used for gathering data from metric sources. countMetrics compares two time series, indicating the ratio of the count of good values to total values for the measured occurrences.

❗If the countMetrics field is defined, it's not possible to set rawMetric on the SLO level.
countMetrics.incremental
mandatory
booleanDepending on the method of counting data (check the SLO calculations guide for more details):
• If set to true (incremental method), Nobl9 expects the value of a metric to be the current sum of some numerator
• If set to false (non-incremental method), Nobl9 expects it to be the components of the sum
countMetrics.good
mandatory
metricReceived data is used to compare objective (threshold) values to find good values (see the note below).
countMetrics.total
mandatory
metricReceived data is used to compare objective (threshold) values to find a total number of metrics (see the note below).
sli values for good and total

When choosing the query for the ratio SLI (countMetrics), keep in mind that the values ​​resulting from that query for both good and total:

  • Must be positive.
  • While we recommend using integers, fractions are also acceptable.
    • If using fractions, we recommend them to be larger than 1e-4 = 0.0001.
  • Shouldn't be larger than 1e+20.
threshold values

Nobl9 uses the threshold value to identify specific objectives to enable uniqueness in error budget calculations.

Set a unique target value across all objectives within one composite SLO. Each objective of the SLO must have unique values.

If you apply an SLO using countMetrics with multiple objectives, make sure that the value for each objective is unique:

  ...
objectives:
- countMetrics:
...
name: objective-1
target: 0.95
value: 1
- countMetrics:
...
name: objective-2
target: 0.91
value: 2

For more details, check Composite guide.

Project

Projects are the primary grouping of resources in Nobl9. For more details, see projects in the Nobl9 platform.

General example for kind:Project
apiVersion: n9/v1alpha
kind: Project
metadata:
name: string # Mandatory
spec:
description: string # Optional

If you describe infrastructure as code, you can create a project with the same convention. You can find more details in our Terraform documentation.

RoleBinding

A single RoleBinding object allows the definition of the relation between exactly one user and exactly one role. Refer to RoleBinding for more details about managing role bindings via sloctl.

General example for kind: RoleBinding
apiVersion: n9/v1alpha
kind: RoleBinding
metadata:
name: string # Mandatory, role name followed by username; for example, project-owner-adam
spec:
projectRef: string # Mandatory, referenced project
roleRef: string # Mandatory, referenced role
user: string # Mandatory, Okta User ID

Notes on fields specific to RoleBinding:

FieldTypeDescription
metadata.name
mandatory
stringConstraints:
• The name must follow conventions defined in DNS RFC 1123. Refer to YAML Guide for further details.
• If you create RoleBinding manually with sloctl, you can put any valid string for the name.
• The name must be unique in an organization (for the Organization roles) or a project (for the Project roles).
RoleBinding created with sloctl is edited in Nobl9 UI. If you create project-owner-adam with sloctl, this object will be available on the Settings > Access Controls tab list in the UI. Then, you can edit the project-owner-adam object on the Users list.
• If you configure a role in the UI first, it will generate a UUID for the name, and you need to get the RoleBinding through sloctl.
spec.projectRef
optional
stringThe project in which we want the user to assume the specified role.
spec.roleRef
mandatory
stringThe role you want the user to assume.
spec.user
mandatory
stringAn Okta User ID that can be retrieved from the Nobl9 UI (Settings > Access Controls).

If you describe infrastructure as code, you can manage role bindings with the same convention. You can find more details in our Terraform documentation.

Service

A service in Nobl9 is a high-level grouping of service level objectives (SLOs). A service can represent a logical service endpoint like an API, a database, an application, or anything else you care about setting an SLO for. Every SLO in Nobl9 is tied to a service, and service can have one or more SLOs.

General example for kind: Service
apiVersion: n9/v1alpha
kind: Service
metadata:
name: string # Mandatory
displayName: string # Optional
project: default # Mandatory, string
spec:
description: string # Optional

If you describe infrastructure as code, you can create a service with the same convention. You can find more details in our Terraform documentation.

SLO

An SLO is a target value or range of values for a service that is measured by a service level indicator (SLI). SLOs allow you to define the reliability of your products and services in terms of customer expectations. You can create SLOs for user journeys, internal services, or even infrastructure.

General YAML for kind: SLO
apiVersion: n9/v1alpha  # Mandatory
kind: SLO # Mandatory
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Mandatory
spec:
composite: # Optional structure for a composite SLO
target: float64 # Defined target for the SLO
burnRateCondition: # If budgetingMethod is set to Timeslices, this field should be removed
value: float64 # Mandatory
op: gte # Mandatory, gte is the only value accepted; any other value will result in a validation error
budgetingMethod: Occurrences | Timeslices # Mandatory, enum
description: string # Optional, max 1050 characters
service: string # Mandatory, name of the service you defined (must be in the same project as the SLO)
indicator:
metricSource:
name: string # Mandatory, name of the data source
project: string # Optional, if not defined, it is the same project as the SLO
kind: string # Optional, defaults to "Agent" (possible values: Agent)
rawMetric: # RawMetric must be defined here once, or defined per each objective
query:
objectives: # You can define from 1 to 12 objectives per SLO
- target: numeric # Numeric, first objective defined for the composite SLO (example values)
op: lte | gte | lt | gt # Mandatory enum for rawMetric only
displayName: string # Optional
value: numeric # Mandatory
rawMetric:
query:
- target: numeric # Numeric, second objective defined for the composite SLO
op: lte | gte | lt | gt # Mandatory enum for rawMetric only
displayName: string # Optional
value: numeric
rawMetric:
query:
timeWindows:
# Exactly one of the following, depending on the type of time window:
# Rolling time window
- unit: Day | Hour | Minute # Mandatory, enum
count: numeric
isRolling: true
# or
# Calendar-aligned time window
- unit: Year | Quarter | Month | Week | Day # Mandatory, enum
count: numeric # Count of time units; for example, count: 7 and unit: Day means 7-day window
calendar:
startTime: "2020-01-21T12:30:00" # Date with time in 24h format, format without time zone
timeZone: America/New_York # Name as in IANA Time Zone Database
isRolling: false # Boolean, false or not defined
alertPolicies:
- string # The name of the alert policy associated with this SLO (must be from the same project as the SLO).
# You can define 0 to 5 alert policies per SLO.
attachments:
# You can add up to 20 links to an SLO.
- displayName: string # Optional, display name for the title of the link; max. length: 63 characters. The URL is used as a link title when the Display Name field is empty.
url: string # The URL to the service related to the SLO

FieldTypeDescription
spec.composite
optional
n/aOptional structure for configuring a Composite SLO.
spec.composite.target
mandatory*
float64* Mandatory provided that the spec.composite field is defined.
spec.composite.burnRateCondition
optional
n/aOptional structure. Mandatory provided the spec.budgetingMethod field is set to Occurrences.
spec.composite.burnRateCondition.value
mandatory
float64Must be a number in the range: (0, 1000].
spec.composite.burnRateCondition.op
mandatory
stringThe only value accepted in this field is gte.
budgetingMethod
mandatory
enumOne of Occurrences | Timeslices):

Occurrences method uses a count ratio of good events to total events. See Occurrences to learn more
Timeslices method uses a ratio of good time slices vs. total time slices in a budgeting period. See Timeslices to learn more

If you describe infrastructure as code, you can define your SLO with the same convention. You can find more details in our Terraform documentation.