# Choosing targets and understanding inheritance

Service Health gives each service a tier and lets its APIs inherit objectives. This guide explains how to choose targets, where each value comes from and how to make an exception without losing track of it.

Read [What is an SLO?](/docs/service-health/slos) first if objectives are unfamiliar.

## Service tiers

| Tier | App label | How to think about it |
| --- | --- | --- |
| 1 | Critical | Services whose failure or delay customers feel immediately |
| 2 | Standard | Normal services with a clear reliability expectation |
| 3 | Best effort | Services where more delay or failure can be tolerated |

An admin confirms a service's tier in **Admin → Services**. The tier is a choice about the service's role, not a rating of its team.

## The strictness presets

**Admin → SLOs → How strict to be** sets defaults for tiers that have no targets of their own. Each pair below is speed / success:

| Preset | Tier 1 | Tier 2 | Tier 3 |
| --- | --- | --- | --- |
| Relaxed | 99.5% / 99.9% | 98% / 99.5% | 90% / 99% |
| Standard | 99.9% / 99.95% | 99% / 99.9% | 95% / 99.5% |
| Strict | 99.95% / 99.99% | 99.5% / 99.95% | 99% / 99.9% |

These are starting points supplied by the app. They are not an industry certification or a promise that the same targets suit every service.

## How inheritance works

Targets resolve from the most specific setting available:

```text
strictness preset → tier → service → API
```

A tier can replace its preset. A service can replace its tier's speed or success target. An API can replace its service's target, with a reason people can read. Each field inherits independently: overriding speed does not automatically override success.

For example, a Standard Tier 2 service inherits 99% speed and 99.9% success. If its export API gets a 98% speed override, the API still inherits 99.9% success. Changing the tier's speed later updates the service and other APIs, while the export API keeps its own choice.

The objective view says whether a value is **Tier default**, **Set on** the service or **Set on this API**. **Reset to inherited** removes the exception so future changes above it flow through again.

## The slow line

The slow line is the duration a call must exceed to spend speed budget. Its default is 500 ms. You can choose 100, 200, 300, 500 or 800 ms, or 1, 2 or 5 seconds, from the thresholds the connector counts.

The line also inherits through tier, service and API, with a common default when the tier has none. A change uses the stored threshold counts on the next read; it does not require a different pipeline.

The service-wide budget always uses the service's own line and target. Making one API's line more generous does not make the same calls faster for the service-wide budget.

## Windows and actions belong to the tier

Each tier sets its rolling window to 7, 28 or 30 days, with 28 as the default. It also chooses what happens **When it burns**:

- Alert the team, then raise a ticket.
- Raise a ticket only.
- Nothing, show it only.

These actions are separate from deciding whether an objective is healthy. Automatic tickets also need the Jira settings described in [Alerts and Jira tickets](/docs/service-health/alerts-and-tickets).

## Before saving a change

Check who inherits it, read the preview, and record why a specific API needs an exception. Prefer a small number of understandable exceptions over a target for every endpoint. Members can inspect the rules even when they cannot edit them.

Admin editors share a draft across tabs. Review the pending changes and use **Apply** to save them together. SLOs, exclusions and access take effect when applied; source, service registry, endpoint and Jira changes need the data or setup to rebuild before their effects appear.

If a chosen line or success measure is not available for some stored calls, the app cannot invent it. A missing reading needs data, rather than an easier target.

## Learn more

- [Error budgets and burn rate](/docs/service-health/error-budgets)
- [Endpoints and exclusions](/docs/service-health/endpoints-and-exclusions)
- [Google SRE workbook: Implementing SLOs](https://sre.google/workbook/implementing-slos/)