Service level objectives

1. Click the filter icon to open the filter panel, which allows you to filter SLOs by:
   • Status: Filter by SLO performance status
     • All: Display all SLOs
     • In target: Display only SLOs meeting their target
     • Out of target: Display only SLOs not meeting their target
   • Tags: Select one or more tags to filter SLOs by their assigned tags
   • Blueprint: Filter by indicator type
     • All: Display all blueprint types
     • Availability: Display only availability SLOs
     • Custom: Display only custom SLOs
     • Latency: Display only latency SLOs
     • Saturation: Display only saturation SLOs
     • Traffic: Display only traffic SLOs
   • Entity Type: Filter by the type of entity being monitored
     • Application
     • Website
     • Synthetic Tests
     • Infrastructure
2. After selecting your filter criteria, click Filter to apply the filters. Click Clear to reset all filters and return to the unfiltered view.

The table displays the following information:

• Name: The name of the SLO. The color of the border on the left signifies the current status of the service level indicator (SLI).

• Entity type: The type of entity that is being monitored, such as an application, website, synthetic test, host, or Kubernetes cluster.

• Entity name: The name of the specific application, website, or synthetic tests that is associated with this SLO. For infrastructure SLOs, the value is shown as "aggregated" because the entity is dynamic.

• Blueprint: The indicator type that is being measured.

  • Latency: Measures how fast the service responds relative to a set threshold.
  • Availability: Measures how often a service responds without errors.
  • Traffic: Measures how much traffic a service is receiving.
  • Saturation: Measures resource utilization relative to a set threshold.
  • Custom: Measures the count of good or bad events by using user-defined filters.

• Error Budget Remaining: Indicates how much of your error budget is available. The value is represented in minutes, calls, beacons, results, or metric snapshots, depending on the selected entity type and indicator type. Details about the time window configuration of SLOs are also displayed.

• Status/Target: Displays the current status of the SLO represented in a percentage value, along with the desired target. If the status meets the target, it is colored green until your error budget is depleted; it is colored red.

• Tags: Displays the tags that are associated with the SLO, which can be used to filter the view for related SLOs.

• Teams: Lists the teams associated with the SLO, which determines access permissions.

• Actions: Contains edit, copy, and delete buttons.

Select the entity type to measure for your SLO. You can define and measure performance targets for the following entity types:

• Application: Measure the performance of calls in an application perspective.
• Website: Measure the performance of beacons and traces in a website.
• Synthetic Tests: Measure the performance of the results of one or more synthetic tests.
• Infrastructure: Measure the performance of infrastructure entities such as hosts, containers, or other infrastructure components.

Configure the scope to specify what data to measure. The scope configuration depends on the entity type.

Define the SLI to measure for the entity.

You can select a Blueprint to define the type of indicator. The available blueprints depend on the entity type:

• For Application and Website entities: Latency, Availability, Traffic, and Custom
• For Synthetic Tests entities: Latency, Availability, and Traffic
• For Infrastructure entities: Saturation and Custom

The indicator is used to specify the metric and measurement type that are used to calculate the SLO status and error budget.

• Latency: Measures response time for calls, beacons, or test results against a specified threshold. The threshold is specified in milliseconds (ms). The Latency blueprint supports two types of measurements:
  • Time-based: The response time for all calls, beacons, or test results are aggregated into one-minute buckets. The error budget is measured in minutes and is a static value that is derived from the SLO target and the duration of the SLO time window. If the aggregated result for each minute exceeds the specified threshold, it is deemed to be a bad minute and the error budget is reduced. You can also specify the type of aggregation that is used from the following options:
    • Mean
    • Min
    • Max
    • Percentile (25, 50, 75, 90, 95, 98, 99)
  • Event-based: The response time for each call, beacon, or test result is compared to the specified threshold and determined to be a good or bad event. Error budget is measured in calls, beacons, or results and is derived from the SLO target and the total number of events during the SLO time window. Since the total number of events is changing over the duration of the SLO time window, the total error budget is a dynamic value.
• Availability: Measures the success rate of calls, beacons, or test results over a defined time period. The threshold is set as a percentage (%). The Availability blueprint supports two types of measurements:
  • Time-based: The success rate for all calls, beacons, or test results are aggregated into one-minute buckets. Error budget is measured in minutes and is a static value derived from the SLO target and the duration of the SLO time window. If the aggregated result for each minute is less than the specified threshold, it is deemed to be a bad minute and the error budget is reduced. Currently only mean aggregation is supported for Availability blueprints.
  • Event-based: The overall success rate for the calls, beacons, or test results is calculated over the SLO time period. The error budget is measured in calls, beacons, or results and is derived from the SLO target and the total number of events during the SLO time window. Since the total number of events is changing over the duration of the SLO time window, the total error budget is a dynamic value.
• Traffic: Measures the load (calls, beacons, or test results) a system encounters over time. This is a time‑based measurement where the number of events per minute is compared to a defined threshold. If the threshold is not met, that minute is considered bad and the error budget is reduced. You can also specify the event type to count:
  • All beacon count (for websites), All calls (for applications), or All results (for synthetic tests): This can be used to measure the overall system traffic for the specified entities.
  • Beacon error count (for websites), Erroneous calls (for applications), or Erroneous results (for synthetic tests): This can be used to focus the measurement only on erroneous traffic.
• Saturation: Measures resource utilization against a specified threshold. The Saturation blueprint is only available for Infrastructure entity types. There are two types of measurements for the Saturation blueprint:

  • Time-based: Infrastructure metric values are aggregated into one-minute buckets. The error budget is measured in minutes and is a static value that is derived from the SLO target and the duration of the SLO time window. If the aggregated result for each minute exceeds the specified threshold, it is deemed to be a bad minute and the error budget is reduced. You must specify:

    • Metric: The infrastructure metric to measure
    • Aggregation: The type of aggregation (Mean, Min, Max, or Percentile: 25, 50, 75, 90, 95, 98, 99)
    • Operator: The comparison operator (>, >=, <, <=)
    • Threshold: The threshold value for comparison

  • Event-based: Infrastructure metric values are retrieved at 10-second intervals. The error budget is measured in metric snapshots and is a static value that is derived from the SLO target and the duration of the SLO time window. Since metric snapshots are taken at a constant 10-second interval, the total number of snapshots is predetermined and does not change over the duration of the SLO time window. You must specify:

    • Metric: The infrastructure metric to measure
    • Operator: The comparison operator (>, >=, <, <=)
    • Threshold: The threshold value for comparison

    The aggregation type is automatically selected based on the threshold operator:

    • For > or >= operators: MAX aggregation is used to ensure that any spike above the threshold within the 10-second window is captured as a potential breach.
    • For < or <= operators: MIN aggregation is used to ensure that any dip below the threshold within the 10-second window is captured as a potential breach.
• Custom: Use custom filters to specify the definition of good and bad events. This is an event-based measurement.

  • For Application and Website entity types: You can define filters for good and bad calls or beacons:

    • Successful events: Specify filters to identify successful beacons or calls. These filters can be combined to create composite queries as needed. If only successful events are defined, events that do not match the filter are assumed to be unsuccessful.
    • Unsuccessful events (optional): Optionally specify filters for unsuccessful beacons or calls. If the unsuccessful events filter is defined, events that do not match either the successful or unsuccessful filters are excluded from the measurement.

  • For Infrastructure entity types: You can define metric-based conditions for good and bad events. You must specify:

    • Good events: Define the metric, operator, and threshold for good events
    • Bad events: Define the metric, operator, and threshold for bad events

    The metrics used to define good and bad events can be the same or different. Unlike saturation‑based (time‑ or event‑based) indicators, this approach allows flexible, custom SLO definitions based on your infrastructure monitoring needs.

Define the overall SLO target value and details for the SLO time window.

• SLO Target: Specify the target percentage that your entity should be meeting when it is performing correctly.

• Time Window: Specify the type of time window for the SLO.
  • Fixed: A time window with a distinct start time and duration. For example, you can configure a fixed one-week window that starts on 2020-01-01. The time window will be automatically reset to the next week (2020-01-08) when the week is completed.
  • Rolling: A dynamic time window with a fixed window size, where the end is defined by the global time picker's end date and time selection. For example, the rolling time window enables the ability to always see the last week.
• Length: The duration of the SLO time window, which is specified in days, weeks, or calendar months.
  • For calendar month selection: Available only for fixed time windows. The time window aligns with calendar month boundaries (first day to last day of each month). If an SLO is created mid-month, the initial measurement period runs from the creation date through the end of that month (a partial period), with subsequent periods following complete calendar months.
• Bind time zone: Enable or disable the binding of the time zone to the SLO time window. If it is not bound to any time zone, UTC is selected by default.
• Time zone: Specify the time zone for the SLO time window. For reference, the full list of valid time zone IDs can be found here.

• Start: For Fixed time windows, the day and time to initiate the SLO calculation.

After entering values for SLO Target and Time window, the error budget is displayed.

• For time-based blueprints, this is a true error budget in minutes as determined by the time window length and the SLO target.
• For event-based blueprints, this is an estimated error budget based on the calls or beacons encountered over the prior SLO time period, along with the specified time window length and SLO target.