Service Levels: Objectives
Overview
Use this page to review the objective catalog and open an objective for compliance details. A service level objective (SLO) is a measurable target, such as 99.9% availability or a 95% transaction-success rate, that a service must meet over a defined time window. This page gives you a single, read-only view of every SLO configured in the platform, so you can scan status without opening each objective individually.
Objectives themselves are created and tuned in Configuration: Service Levels: Objectives, where you set the type, target, window, bucket, and the data source that feeds compliance calculations, typically an uptime check or transaction monitor. Once an objective exists, its ongoing compliance feeds Service Levels: Violations when the target is breached, and rolls up into Service Levels: Health and Service Levels: Dashboard.
From this page you can scan every objective's type, target, window, bucket, and current state at a glance, refresh the list to pull the latest figures, select an objective's name to open its compliance, history, error budget, and violations, or select Manage in Config to jump to the objective definitions.
Key concepts
- Service level objective (SLO) - A measurable target, such as an availability percentage or a transaction response-time threshold, that a service must meet over a defined window. Each row in this catalog is one SLO. (related: Configuration: Service Levels: Objectives)
- Error budget - The amount of allowed shortfall against the target within the current window before the objective counts as breached. It is consumed by outages or slow responses and exposed when you open an objective's detail. (related: Service Levels: Violations)
- Window - The rolling time span over which compliance toward the target is calculated, for example the last 30 days.
- Bucket - The measurement interval that compliance data is aggregated into within the window, for example every 5 minutes.
When to use it
- Before or during a service-level review to confirm every objective is still meeting its target.
- After an outage or performance incident, to check whether an availability or transaction-SLA objective was breached.
- When you need a quick status check across all tracked services without opening each one individually.
- Before editing an objective's definition, to confirm which objectives currently exist and what they are called.
- When onboarding to a service, to see which objectives are already tracked for it.
Before you begin
- At least one service level objective must already be defined in Configuration: Service Levels: Objectives; until one exists, this table has no rows to show.
- The data source behind an objective, such as an uptime check, must be configured and reporting in Uptime Monitoring: Checks so compliance figures are current.
- Your account needs permission to view Service Levels pages; the Manage in Config control additionally requires configuration permission, set in Operations: Permissions.
Common workflows
Check whether a service is meeting its objective
Persona: Load-test operator or admin
- Open Service Levels: Objectives from the left navigation.
- Expect: The table lists every configured objective with its type, source, target, window, bucket, and state.
- Locate the objective in the OBJECTIVE column and select its name.
- Expect: The objective's compliance, history, error budget, and violations detail opens.
Verify: The detail view shows whether current compliance is above or below the TARGET value shown on the catalog page, confirming the objective's actual status.
Refresh compliance figures before a status review
Persona: Admin preparing a service-level report
- Select Refresh.
- Expect: The table reloads and the STATE and TARGET figures reflect the latest available compliance data.
Verify: The objective rows remain the same but reflect current, not cached, compliance figures before you report on them.
Steps
Step 1
Open Service Levels: Objectives from the left navigation.
Expected result: The read-only objective catalog loads, listing each configured objective, including Portal availability and Portal response under 2 s, with its TYPE, SOURCE, TARGET, WINDOW, BUCKET, and STATE.
This gives you a single list of every SLO so you can spot which ones need attention before drilling into details.
- The OBJECTIVE column names are links; select one to open its compliance, history, error budget, and violations.
- Refresh reloads the table in place without navigating away.
-
Manage in Config opens the objective definitions for editing.
Column reference
| Column | What it shows | How to read it |
|---|---|---|
| OBJECTIVE | Identifies the specific SLO by name, for example svc.lg.fulmar. |
Select the name to open that objective's compliance, history, error budget, and violations detail. |
| TYPE | Classifies what the objective measures: Availability tracks uptime percentage; TransactionSla tracks a transaction's performance against a response-time threshold. | Availability means the target is an uptime percentage; TransactionSla means the target is a transaction-level performance threshold. |
| SOURCE | Names the monitoring data feeding the objective's compliance calculation. | If compliance figures look stale, confirm this source is actively reporting data for the underlying check. |
| TARGET | The compliance threshold the objective must meet within its window. A higher target, such as 99.9% versus 95%, leaves a smaller error budget, so fewer failures are tolerated before the objective is breached. | Compare this value against the objective's actual compliance in its detail view to see how much error budget remains. |
| WINDOW | The rolling period over which compliance toward the target is calculated. A longer window smooths out short-lived incidents; a shorter window surfaces recent degradation faster. | Use this to judge how far back a breach shown in the objective's history can still affect its current compliance. |
| BUCKET | The granularity that measurement data is aggregated into within the window. A smaller bucket gives finer-grained compliance data; a larger bucket smooths short spikes. | Shorter bucket values mean the objective's history can show brief dips that a coarser bucket would average away. |
| STATE | Shows whether the objective is currently being evaluated. | Active means the objective is currently tracked and contributing to Service Levels: Health and Service Levels: Dashboard. |
Controls reference
Refresh
Reloads the objective catalog with the latest compliance figures from the underlying data sources.
When to use: Use it before a review or after a known incident to make sure you are looking at current, not cached, compliance status.
Side effects: Read-only: it reloads the table in place and does not change any objective's configuration or state.
Manage in Config
Navigates to the objective definitions in Configuration: Service Levels: Objectives.
When to use: Use it when you need to create a new objective or edit an existing one's type, target, window, bucket, or source.
Side effects: Navigation only from this page; any create or edit actions happen on the configuration page, not here.
Verify the result
The table lists every active service level objective with its type, target, window, bucket, and state, confirming the catalog loaded correctly. Each row's STATE badge shows Active for objectives currently being evaluated. If you select an objective's name, its compliance, history, error budget, and violations detail should open. If the table is empty, no objectives have been defined yet; if a row's figures look outdated, select Refresh before concluding an objective is out of compliance.
Troubleshooting
- Symptom: The table shows no objectives. Fix: No SLOs have been created yet; select Manage in Config to define one in Configuration: Service Levels: Objectives.
- Symptom: Selecting an objective's name does nothing. Fix: Confirm your account has permission to view Service Levels detail pages in Operations: Permissions.
- Symptom: TARGET or STATE values look outdated. Fix: Select Refresh to reload the latest figures; if they still look stale, confirm the SOURCE check is reporting data in Uptime Monitoring: Checks.
- Symptom: Manage in Config is missing or does nothing. Fix: Confirm your account has configuration-level permission for Service Levels, set in Operations: Permissions.
Related articles
- Prerequisite: Configuration: Service Levels: Objectives - objectives are created and edited here, not on the read-only catalog page
- Next step: Service Levels: Violations - shows breaches logged when an objective's error budget is exceeded
- See also: Service Levels: Health - rolls up objective compliance into an overall health view
- See also: Service Levels: Dashboard - summarizes service level status alongside this objective catalog
- Prerequisite: Uptime Monitoring: Checks - the uptime source that feeds the SOURCE column's compliance data