Service Levels: Operations

Updated

Service Levels: Operations

Overview

Use this page to recalculate service level objective data after a correction. Service Levels: Operations is the maintenance console for the data behind your service level objectives (SLOs): it controls how long raw and rolled-up measurements are kept, lets you force a recomputation of compliance figures when the underlying data was wrong, and lets you export that data or get alerted when an objective breaches or burns through its error budget.

Services and objectives are defined on Configuration: Service Levels: Services and Configuration: Service Levels: Objectives before this page is useful; those definitions populate the Service and Objective scope dropdowns here. The retention policy you set determines how far back objective history goes on pages such as Service Levels: Health and Service Levels: Violations, and alert rules created here fire the events those pages surface downstream.

On this page itself, you can adjust and apply retention and rollup settings, trigger an immediate compaction, scope and launch a recalculation job, run and download data exports, and create, edit, or delete SLO alert rules while reviewing recent alert events.

Key concepts

  • rollup - A pre-aggregated summary of raw service-level measurements at a coarser time granularity (hourly or daily) kept after the raw 5-minute data is purged, so long-term history takes less storage. (related: Configuration: Service Levels: Storage)
  • compaction - The maintenance job that applies the saved retention policy: it purges data older than the configured windows and consolidates rollups. (related: Configuration: Service Levels: Storage)
  • recalculation - Recomputing an objective's compliance and error-budget figures from underlying raw data for a given time range, typically after a data correction. (related: Service Levels: Objectives)
  • alert rule - A condition tied to a service level objective that fires an alert event, with an assigned severity and an enabled or disabled state, when the objective breaches or its error budget burns too fast. (related: Service Levels: Violations)

When to use it

  • You need to extend or shorten how long raw and rolled-up service level data is kept before it is purged.
  • Historical SLO figures look wrong after a data correction and need to be recomputed for a specific service, objective, and time range.
  • You need to export service level data for a service and objective over a date range for offline analysis or compliance reporting.
  • You want to be notified automatically when a service level objective breaches its target or burns through its error budget, by creating an alert rule.
  • You need to review which alert rules are configured and check recent alert events fired against them.

Before you begin

  • At least one service exists, created on Configuration: Service Levels: Services.
  • At least one service level objective exists for that service, created on Configuration: Service Levels: Objectives, since Service and Objective dropdowns on this page are populated from those definitions.
  • The objective has accumulated enough snapshot history that a recalculation or export over your chosen time range will return meaningful data.
  • Your account has permission to modify retention settings, trigger recalculations, and manage alert rules, confirmed on Operations: Permissions.

Common workflows

Recalculate service level objective data after a correction

Persona: Service Level administrator

  1. Open the Recalculation panel and select the Service and Objective you need to recompute, or leave All services and All objectives selected.
    • Expect: The dropdowns show your selection, or remain on their All defaults.
  2. Set the Recalculation start timestamp and Recalculation end timestamp to the exact period affected, and enter a short note in Reason.
    • Expect: The two timestamp fields show your chosen range and Reason holds your note.
  3. Click Start recalculation.
    • Expect: A recalculation job is submitted for the selected scope and range.

Verify: Click Refresh later and confirm no recalculation job is still shown as running; the objective's compliance figures for that range now reflect the recomputed values on pages such as Service Levels: Health.

Create an alert rule for an SLO breach

Persona: Service Level administrator

  1. Click + New rule in the Alert rules panel.
    • Expect: The alert rule form opens with empty Rule name, Service, Objective, Condition, Severity, and Enabled fields.
  2. Enter a Rule name such as svc.lg.fulmar, select the Service and Objective to watch, and set the Condition and Severity.
    • Expect: The form reflects your entries and the rule is scoped to that specific objective.
  3. Click SRE defaults to prefill multi-window burn-rate tiers, or use Add tier to add tiers manually, then click Save rule.
    • Expect: The form closes and the new rule appears as a row under RULES.

Verify: The Alert rules panel's RULES column lists the new rule instead of No alert rules configured.; once a breach occurs, an entry appears under RECENT EVENTS.

Steps

Step 1

Open the Service Levels: Operations page.

Expected result: The page loads showing the Retention and rollups, Recalculation, Exports, and Alert rules panels; the Alert rules panel shows No alert rules configured. and No alert events yet. since none have been created.

This is the starting point for every retention, recalculation, export, or alert-rule task on the page.

  • A Credentials expiring banner may appear if a credential used elsewhere in the platform is close to expiring; it links to Configuration → Credential Profiles and is unrelated to this page's own settings.
  • Retention and rollups shows three number fields (5m days, hourly months, daily months) with Save retention and Run compaction below them.
  • Recalculation shows Service/Objective dropdowns, a start/end timestamp pair, a Reason field, and Start recalculation. Service Levels: Operations - step 1

Step 2

Click Refresh in the page header.

Expected result: The page reloads the retention, recalculation, export, and alert rules panels from the server; because no settings, jobs, or rules have changed yet, the values and the No alert rules configured. and No alert events yet. messages remain the same.

Refreshing confirms the page reflects the latest retention, job, and alert-rule state before you decide whether to trigger another operation.

  • Refresh sits in the page header, to the right of the breadcrumb and above the panels. Service Levels: Operations - step 2

Field reference

Field Purpose Format / Validation Required Default
5m days Sets how many days of raw 5-minute-resolution snapshots are kept before being purged. A higher value preserves fine-grained drill-down history longer at the cost of more storage; a lower value frees storage sooner but limits how far back you can inspect short-interval detail. Whole number (days) No 180
hourly months Sets how many months of hourly rollups are retained. Raise it to keep mid-resolution trend history for month-over-month comparisons longer; lower it to reduce storage once daily rollups are sufficient. Whole number (months) No 24
daily months Sets how many months of daily rollups are retained, the longest-lived granularity on this page. Raise it for long-term or compliance reporting; lower it if only recent daily trends matter. Whole number (months) No 60
Service (Recalculation) Scopes the recalculation to one service, or leave All services to recompute every service's objectives in the selected time range. Narrowing the scope shortens the job and limits its impact to the service you are correcting. Dropdown No All services
Objective (Recalculation) Scopes the recalculation to a single service level objective within the selected service, or leave All objectives to recompute every objective for that service. Dropdown No All objectives
Recalculation start timestamp Sets the beginning of the date/time range that will be recomputed from raw data. Use it with the end timestamp to bound the job to the exact window affected by a data issue instead of reprocessing all history. Date/time No current date minus 1 day
Recalculation end timestamp Sets the end of the recalculation date/time range; data after this point is not recomputed. Date/time No current date/time
Reason Free-text note recorded with the recalculation job, for example to document why the data needed correcting. Not required, but useful for later audit of why historical figures changed. Free text No -
Service (Exports) Selects which service's data to include in the export. It defaults to a specific configured service rather than All services, so confirm it before exporting if you intended a different one. Dropdown No Digital Workspace
Objective (Exports) Scopes the export to a single objective, or leave All objectives to export every objective under the selected service. Dropdown No All objectives
Export start timestamp Sets the beginning of the date range included in the export file. Date/time No current date minus 7 days
Export end timestamp Sets the end of the date range included in the export file. Date/time No current date/time

Controls reference

Refresh

Reloads the page's retention settings, recalculation/export job statuses, and alert rules and events from the server.

When to use: After triggering a recalculation, compaction, or export elsewhere, to pick up updated status without reloading the browser.

Side effects: Read-only: re-fetches current data, does not change any settings or records.

Save retention

Persists the 5m days, hourly months, and daily months values as the new retention policy.

When to use: After changing any of the three retention fields, before relying on them to take effect.

Side effects: Mutating: updates the stored retention policy. Does not by itself purge or compact data; Run compaction applies the policy.

Run compaction

When to use: After saving shorter retention values and you want storage reclaimed right away, or to force rollups to catch up.

Side effects: Mutating and destructive: purges raw data older than the configured retention windows. This cannot be undone.

Start recalculation

Submits a background job that recomputes compliance and error-budget figures for the selected service, objective, and time range from underlying raw data.

When to use: After a data correction, an agent outage, or any event that left computed SLO figures for a period inaccurate.

Side effects: Mutating: overwrites previously computed compliance values for the selected scope and range.

Export

Starts an export job that packages service level data for the selected service, objective, and date range into a downloadable file.

When to use: When you need service level data outside the platform, for example for a compliance report.

Side effects: Mutating: creates an export job; does not change any SLO or alert data.

Download

Downloads the file produced by a completed export job.

When to use: Once an export job you started has finished.

Side effects: Read-only: retrieves the already-generated file, no data changes.

New rule

Opens a form to define a new alert rule for a service level objective, including Rule name, Service, Objective, Condition, Severity, and Enabled state, plus burn-rate alert tiers.

When to use: When you want to be notified automatically if an objective breaches its target or burns through its error budget too fast.

Side effects: Opens a form only; nothing is saved until Save rule is clicked.

Edit

Opens the same alert rule form pre-filled with the selected rule's current settings.

When to use: To change an existing rule's condition, severity, scope, or tiers.

Side effects: Opens a form only; changes are not applied until Save rule is clicked.

Delete

Removes an alert rule after you confirm a prompt warning that it will stop firing and cannot be undone.

When to use: When a rule is no longer needed, for example after decommissioning the service or objective it watched.

Side effects: Mutating and destructive: permanently deletes the rule; it stops firing future alert events immediately.

SRE defaults

Prefills the rule's burn-rate alert tiers with the canonical multi-window, multi-burn-rate tier set from the Google SRE Workbook, sized for a 30-day error budget.

When to use: When creating a burn-rate alert rule and you want a proven starting set of tiers instead of building them from scratch.

Side effects: Mutating within the open form only: replaces the current tier rows; nothing is saved until Save rule is clicked.

Add tier

Adds another burn-rate alert tier row to the rule being edited.

When to use: When you need an additional severity tier beyond the current set, for example to catch a slower, sustained burn alongside a fast spike.

Side effects: Mutating within the open form only; not saved until Save rule is clicked.

Remove tier

Removes a single burn-rate tier row from the rule being edited.

When to use: When a rule has more tiers than you need.

Side effects: Mutating within the open form only; not saved until Save rule is clicked.

Cancel

Closes the alert rule form without saving any changes.

When to use: When you decide not to create or update the rule.

Side effects: Discards unsaved form edits; no stored data changes.

Save rule

Creates a new alert rule, or updates the one being edited, with the Rule name, Service, Objective, Condition, Severity, Enabled state, and burn-rate tiers entered in the form.

When to use: After filling in or adjusting the rule's fields and tiers.

Side effects: Mutating: creates or updates the rule record; it appears under RULES and begins evaluating immediately if Enabled is set.

Verify the result

After you click Start recalculation, the job runs against the selected Service, Objective, and time range; clicking Refresh or reopening the page confirms it finished once no recalculation job is reported as still running. The objective's compliance and error-budget figures for that range reflect the recomputed values, visible wherever the objective's history is shown, for example on Service Levels: Health or Service Levels: Violations. If the figures still look wrong, check that the Recalculation start timestamp and end timestamp actually cover the affected period, and that you scoped Service and Objective correctly rather than leaving All services and All objectives selected by mistake.

Troubleshooting

  • Symptom: Run compaction doesn't seem to free any storage. Fix: Confirm you clicked Save retention after lowering 5m days, hourly months, or daily months; compaction applies the last saved policy, not unsaved field values.
  • Symptom: Start recalculation appears to do nothing or figures still look wrong. Fix: Check that the Recalculation start timestamp is earlier than the end timestamp and that the Service/Objective combination actually has data in that range.
  • Symptom: An export contains more or less data than expected. Fix: Re-check the Export start timestamp and Export end timestamp, and confirm the Service and Objective dropdowns are scoped to the one you intend rather than left on their defaults.
  • Symptom: The Alert rules panel still shows No alert rules configured. after opening New rule. Fix: You must complete the form and click Save rule; closing it with Cancel or navigating away discards the new rule.
  • Symptom: Deleting an alert rule removed an alert you still needed. Fix: There is no undo; the confirmation prompt warns the rule will stop firing before deletion, so re-create it with New rule if needed.
  • Symptom: A Credentials expiring banner covers the page. Fix: This refers to a credential used elsewhere in the platform, not to this page's own settings; reissue it under Configuration: Credential Profiles and the banner clears.
Was this article helpful?
0 out of 0 found this helpful