SLO objectives
ConceptProductSince version 1.3.0
Product guide: what the capability brings, for whom, its limits and the version that delivered it - no configuration syntax.
| What it does | Declares availability and latency objectives in the console's configuration, and tracks their remaining error budget and burn rate over several windows; a built-in rule alerts when the budget burns too fast |
| Per group | An objective covers one operation, or - since 1.6.0 - a group: every operation of an upstream, those of an OpenAPI tag, an explicit list (a user journey) or everything (a headline figure on the overview) |
| Why it matters | A team talks about reliability in its own terms: its service, its checkout journey, its overall promise. The computation needs no extra metric series |
| Use cases | Hold 99.9 % on the ordering journey; alert before a month of errors is spent; show management an overall objective |
| Limits | Objectives per group not complete yet: served and tested (unit, contract), but neither the end-to-end proof under an injected outage nor the measurement of the evaluation cost over 30 days is done - the bound of 100 objectives is provisional |
| Since | 1.3.0 (per operation), 1.6.0 (per group) |
| Configure | Reading with the console, SLO objectives on groups of operations |