Service Levels: Operations
Overview
Use this page to manage service-level data retention, recalculations, exports, and alert rules. Service Levels tracks whether a service meets its SLO (service level objective) by storing performance snapshots and recording violations. Raw snapshots accumulate faster than teams need in full detail, historical results sometimes need recomputing after a data problem is fixed, and teams need automated alerts when a service burns through its error budget too fast.
A service and at least one objective must exist first, created on Configuration: Service Levels: Services and Configuration: Service Levels: Objectives; those definitions populate the Service and Objective dropdowns here. The snapshots and violations this page retains, recomputes, or exports are the same data shown on Service Levels: Dashboard and Service Levels: Violations, and alert events raised here are what you check when investigating an incident.
On this page you set a three-tier retention policy and run an on-demand compaction job to apply it immediately, trigger a scoped, date-ranged recalculation with an auditable reason, request a data export for a service, objective, and date range, and manage burn-rate alert rules while reviewing the events they fire.
Key concepts
- Objective - An SLO objective is the measurable target LoadGen evaluates for a service, such as a percentage threshold over a time window. (related: Configuration: Service Levels: Objectives)
- Service - A service is the named application or environment that LoadGen tracks against one or more objectives. (related: Configuration: Service Levels: Services)
- Retention and rollups - Retention controls how long raw 5-minute snapshots, hourly rollups, and daily rollups are kept before older detail is purged or collapsed into a coarser summary. (related: Configuration: Service Levels: Storage)
- Burn rate - Burn rate is how fast a service is consuming its error budget relative to the pace that would exhaust the budget over its full window; alert tiers compare short and long windows of burn rate to catch both fast and slow incidents. (related: Service Levels: Violations)
- Alert rule - An alert rule is a condition tied to a service and objective that raises an alert event on this page when its burn-rate thresholds are breached. (related: Alerting: Triggers)
When to use it
- Raw snapshots are consuming too much storage and you need to tune how long each retention tier is kept.
- You fixed bad or missing source data and need to recompute SLO snapshots and violations for the affected date range.
- You need to export SLO data for a service and objective over a specific period for an external report.
- You want LoadGen to automatically flag a service that is burning through its error budget too fast.
- You are investigating an incident and need to check which alert rules recently fired and when.
Before you begin
- A service must already exist, created on Configuration: Service Levels: Services.
- At least one objective must exist for that service, created on Configuration: Service Levels: Objectives.
- Know the reason you are requesting an on-demand recalculation; it is recorded for the audit trail.
- Have permission to change retention, run compaction and recalculation jobs, and manage alert rules, since every action on this page changes stored data or starts a background job.
Common workflows
Recompute SLO data after fixing bad source data
Persona: Service Levels administrator
- Select the service and objective to recompute in the Recalculation panel, or leave both at All services and All objectives to recompute everything.
- Expect: The Service (Recalculation) and Objective (Recalculation) dropdowns show your selection.
- Set the start and end date fields to the period affected by the bad data.
- Expect: The date fields show the new range.
- Type a short explanation into Reason.
- Expect: The reason text appears in the field.
- Select Start recalculation.
- Expect: The button becomes disabled and a recalculation job starts running in the background.
Verify: After the job completes, the affected objective's snapshots and violations on Service Levels: Dashboard and Service Levels: Violations reflect the corrected data for that date range.
Create a burn-rate alert rule for a service
Persona: Service Levels administrator
- Select New rule in the Alert rules panel.
- Expect: The alert rule form opens with empty service and objective selections.
- Enter a name in Rule name and select the service and objective to monitor.
- Expect: The form shows your rule name and target selections.
- Select SRE defaults.
- Expect: The burn-rate tier list fills with the canonical multi-window, multi-burn-rate thresholds for a 30-day error budget.
- Set Severity, confirm Enabled is on, and select Save rule.
- Expect: The form closes and the new rule appears in the RULES list.
Verify: The RULES list no longer shows 'No alert rules configured.' and instead lists your new rule; once its condition is breached, an entry appears under RECENT EVENTS.
Tune and apply a new retention policy
Persona: Service Levels administrator
- Update 5m days, hourly months, or daily months in the Retention and rollups panel to the values you want to keep.
- Expect: The number fields show your new values.
- Select Save retention.
- Expect: The new retention policy is saved.
- Select Run compaction.
- Expect: A compaction job starts in the background, rolling up and purging data according to the saved policy.
Verify: After the job completes, data older than the new retention windows is no longer queryable at its original resolution, and selecting Refresh shows no compaction job in flight.
Steps
Step 1
Open Service Levels: Operations.
Expected result: The page loads showing the Retention and rollups, Recalculation, Exports, and Alert rules panels, with the Alert rules panel showing 'No alert rules configured.' and 'No alert events yet.'
This is the starting point for every retention, recalculation, export, or alert-rule task on this page.
- Retention and rollups shows 5m days: 180, hourly months: 24, daily months: 60.
- Recalculation and Exports default to All services / All objectives with a pre-filled date range.
-
New rule opens the alert rule form.
Step 2
Select Refresh in the page header.
Expected result: The page reloads its current state; Start recalculation becomes disabled because a recalculation job is already in flight.
Refreshing confirms whether a job started elsewhere is still running before you try to start another one.
- Start recalculation is grayed out while a recalculation is in flight.
-
Refresh itself makes no changes to retention, recalculation, export, or alert-rule data.
Field reference
| Field | Purpose | Format / Validation | Required | Default |
|---|---|---|---|---|
| 5m days | Sets how many days of 5-minute-resolution snapshots LoadGen keeps before they age out. Raise it to keep short-interval detail available for incident investigation longer; lower it to reduce raw-snapshot storage sooner. | integer, days | No | 180 |
| hourly months | Sets how many months of hourly rollups are kept after 5-minute snapshots age out. Raise it to preserve medium-grain trend data for longer comparisons; lower it to reduce rollup storage. | integer, months | No | 24 |
| daily months | Sets how many months of daily rollups are kept, the coarsest and longest-lived retention tier. Raise it to retain long-term history for SLA review; lower it if only recent trends matter. | integer, months | No | 60 |
| Service (Recalculation) | Scopes the recalculation to one service, or leave it at All services to recompute SLO data across every service in the selected date range. | dropdown | No | All services |
| Objective (Recalculation) | Scopes the recalculation to one objective under the selected service, or leave it at All objectives to recompute every objective in scope. | dropdown | No | All objectives |
| Date range start (Recalculation) | Sets the start of the period to recompute. Narrow it to the window affected by a data issue instead of reprocessing all history, which takes longer and rewrites more stored data. | date | No | 2026-10-23 |
| Date range end (Recalculation) | Sets the end of the period to recompute, paired with the start date to bound the recalculation. | date | No | 2026-10-24 |
| Reason (Recalculation) | Records why you requested an on-demand recalculation, for the audit trail you or another administrator can review later. | free text | No | - |
| Service (Exports) | Scopes the export to one service, or leave it at All services to export SLO data across every service in the selected date range. | dropdown | No | Digital Workspace |
| Objective (Exports) | Scopes the export to one objective under the selected service, or leave it at All objectives to export every objective in scope. | dropdown | No | All objectives |
| Date range start (Exports) | Sets the start of the period to export. Match it to the reporting period you need rather than exporting more history than required. | date | No | 2026-10-17 |
| Date range end (Exports) | Sets the end of the period to export, paired with the start date to bound the export. | date | No | 2026-10-24 |
| Rule name | Names the alert rule so you can identify it in the RULES list and in the alert events it generates. | free text | Yes | - |
| Service (Alert rule) | Selects which service this alert rule monitors. | dropdown | - | - |
| Objective (Alert rule) | Selects which objective under that service the rule evaluates against its burn-rate condition. | dropdown | - | - |
| Condition (Alert rule) | Defines the burn-rate threshold comparison against the objective's error budget that causes the rule to fire. | dropdown or expression | - | - |
| Severity (Alert rule) | Sets how urgently this rule's alert events should be treated. Choose a standard severity level; if the rule previously held a legacy or unrecognized severity string, that value stays selectable so you do not lose it by opening the form. | dropdown | - | - |
| Enabled (Alert rule) | Toggles whether the rule actively evaluates and can fire. Turn it off to keep a rule configured but silence it without deleting it. | toggle | No | On |
| Tier name (burn-rate tier) | Labels a burn-rate tier, for example a fast 1-hour window versus a slower 6-hour window, so you can tell tiers apart in the rule and in the events it raises. | free text | No | - |
Column reference
| Column | What it shows | How to read it |
|---|---|---|
| RULES | Lists every alert rule configured for the account, with its target service, objective, and condition. | Until you create a rule, this shows 'No alert rules configured.' Once rules exist, each row offers Edit and Delete for that rule. |
| RECENT EVENTS | Lists the most recent alert events raised by this account's alert rules. | Until a rule fires, this shows 'No alert events yet.' Once an event appears, it identifies which rule and objective breached its burn-rate condition and when. |
Controls reference
Refresh
Reloads the page's current retention settings, job status, and alert rules and events from the server.
When to use: Use it after triggering a compaction, recalculation, or export elsewhere, or when you want to confirm whether a job is still running.
Side effects: Read-only: no data changes. It can disable Start recalculation if it finds a recalculation job still in flight.
Save retention
Saves the current 5m days, hourly months, and daily months values as the account's retention policy.
When to use: Use it after changing any of the three retention fields so the new policy persists.
Side effects: Mutating: updates the stored retention policy. It does not itself delete or roll up existing data.
Run compaction
Starts an on-demand compaction job that rolls fine-grained snapshots into hourly and daily rollups and purges data older than the current retention policy.
Side effects: Mutating and irreversible: deletes or collapses snapshot data older than the retention windows once the job completes.
Start recalculation
Starts a background job that recomputes SLO snapshots and violations for the selected service, objective, and date range.
When to use: Use it after correcting bad source data, backfilling missing monitoring data, or changing an objective's definition, so historical results reflect the fix.
Side effects: Mutating: overwrites previously computed snapshots and violations in the selected range. Disabled while another recalculation job is already in flight.
Export
Starts a background job that generates a downloadable SLO data file for the selected service, objective, and date range.
When to use: Use it when you need SLO data outside the platform, for example for a customer-facing report.
Side effects: Mutating in that it creates a new export job and file; it does not alter the underlying SLO data.
Download
Downloads the file for a completed export job.
When to use: Use it once an export job's status shows complete.
Side effects: Read-only: downloads a file, no data changes.
New rule
Opens a form to create a new alert rule scoped to a service and objective, with its own condition, severity, enabled state, and burn-rate tiers.
When to use: Use it to set up automatic notification when a service's error budget is burning too fast.
Side effects: Opens a form only; nothing is saved until you select Save rule.
Edit
Opens the same rule form pre-filled with the selected rule's current settings.
When to use: Use it to adjust an existing rule's condition, severity, enabled state, or burn-rate tiers.
Side effects: Opens a form only; changes apply only after Save rule.
Delete
Removes an alert rule after you confirm a prompt.
When to use: Use it to permanently stop a rule from firing, for example when the service it targets is retired.
Side effects: Mutating and irreversible: the confirmation prompt states the rule stops firing and the action cannot be undone.
SRE defaults
Populates the rule's burn-rate tiers with the canonical Google SRE Workbook multi-window, multi-burn-rate thresholds for a 30-day error budget.
When to use: Use it as a starting point instead of building burn-rate tiers from scratch.
Side effects: Changes only the open form; nothing is saved until Save rule.
Add tier
Adds an empty burn-rate tier row to the rule being edited.
When to use: Use it to add an extra burn-rate window beyond the SRE defaults, for example to catch a slower-building burn pattern.
Side effects: Changes only the open form; not saved until Save rule.
Remove tier
Removes a burn-rate tier row from the rule being edited.
When to use: Use it to simplify a rule down to fewer burn-rate windows.
Side effects: Changes only the open form; not saved until Save rule.
Cancel
Closes the alert rule form without saving any changes.
When to use: Use it if you opened New rule or Edit by mistake or decide not to proceed.
Side effects: Read-only: discards unsaved form changes.
Save rule
Saves the alert rule, new or edited, with its service, objective, condition, severity, enabled state, and burn-rate tiers.
When to use: Use it once the rule form is complete.
Side effects: Mutating: creates or updates the rule; it appears in RULES and starts evaluating immediately if Enabled.
Verify the result
Each panel reflects the operation you just ran: the retention fields show the values you saved, a triggered compaction or recalculation job disables its button while in flight and re-enables once it finishes, and a requested export eventually offers a Download link for its job. In the Alert rules panel, a rule you saved appears under RULES instead of the empty-state message, and its fired conditions appear under RECENT EVENTS. If a value you changed does not stick, confirm you selected Save retention or Save rule rather than just editing the field, since typing alone does not persist anything. If a job seems stuck, select Refresh to confirm whether it is still in flight before assuming it failed.
Troubleshooting
- Symptom: Start recalculation is disabled. Fix: Select Refresh to confirm whether a recalculation job is already running; the button re-enables once that job finishes.
- Symptom: You changed 5m days, hourly months, or daily months but the values revert after leaving the page. Fix: Select Save retention before navigating away; changing the number fields alone does not persist the policy.
- Symptom: The Alert rules panel still shows 'No alert rules configured.' after filling in the rule form. Fix: Confirm you selected Save rule rather than Cancel to close the form.
- Symptom: An export never shows a Download link. Fix: Select Refresh so the page re-attaches the live progress poller for export jobs still in flight; the link appears once the job completes.
- Symptom: You deleted an alert rule and want it back. Fix: There is no undo; use Edit and turn off Enabled instead of Delete next time you only want to silence a rule temporarily.
- Symptom: An export or recalculation for a service and objective returns no data. Fix: Confirm the date range overlaps a period when that objective was actually being evaluated.
Related articles
- Prerequisite: Configuration: Service Levels: Services - defines the services that populate the Service dropdowns here
- Prerequisite: Configuration: Service Levels: Objectives - defines the objectives that populate the Objective dropdowns and alert rule targets
- See also: Configuration: Service Levels: Storage - related storage configuration for service level data
- Next step: Service Levels: Violations - shows the violations a recalculation or alert rule references
- Next step: Service Levels: Dashboard - reflects the SLO data after retention, compaction, or recalculation changes
- See also: Alerting: Triggers - the platform's broader alerting configuration alongside service-level alert rules