# Tiers and SLA reports

A tier says how critical a service is and what that promises. Catalog measures each service against its targets every month, from the Uptime monitors and On-Call integrations that watch it.

## Tiers

Tiers are your organization's own. Open **Catalog → Settings → Tiers and SLAs**. A new organization starts with **Tier 1** to **Tier 4**; the first tier is the most critical.

Select **Add a tier** to add one. Each tier has a **Name**, a description of what belongs in it (for example "Anything a customer sees or pays through"), a **Colour**, and its targets:

| Target | What it promises |
| --- | --- |
| **Availability** | An uptime percentage, such as `99.9`. |
| **Acknowledged within** | Minutes to acknowledge an alert, per On-Call severity (critical, high, medium, low, info). |
| **Resolved within** | Minutes to resolve an alert, per severity. |
| **Support hours** | Around the clock (24x7), or business hours with a timezone, days and times. |
| **Owner within** | Days a service may go without an owner team. |

Every target is optional. Use the arrows to make a tier **More critical** or **Less critical**; a service's tier number follows the order.

Changing a tier's name, description or targets makes a new version of it. Versions are kept, so a past month's SLA report reads the targets that applied then; **Every version of this tier** lists them. Changing only the colour is not a new version.

A tier is never deleted. **Archive** takes it out of use: it can no longer be chosen, and the services already in it keep it. An organization can have up to 50 tiers in use.

## A service's SLA

Choose a service's **Tier** on its page. The service takes the tier's targets, and its **SLA** section can change any of them for itself: empty fields take the tier's value, shown greyed, and the targets the service changes are marked. A service with no tier has only its own targets.

## Responsibilities

The owner team answers for a service. If you need more, add a RACI under **Responsibilities** on the service's page with **Add a RACI**. Each line is a role and a team or a person:

| Role | Meaning |
| --- | --- |
| **Responsible** | Does the work |
| **Accountable** | Answers for it; exactly one |
| **Consulted** | Asked before a change |
| **Informed** | Told after |

A RACI is optional, saved as a whole, and must have exactly one Accountable line. It can have up to 50 lines.

## The SLA report

Each service's page has an **SLA report** for each of the last twelve calendar months, in UTC. The current month is measured up to now.

To be measured, a service needs what watches it to be tied to it: set the **Catalog service** field on its Uptime monitors and on its On-Call integrations.

- **Availability** is summed over the Uptime monitors tied to the service, with each monitor's checks, and compared with the availability target.
- **Response and resolution** come from the On-Call alerts raised by the integrations and monitors tied to the service, per severity: how many alerts, how many were acknowledged and resolved, the median and 90th percentile times, and how many breached the targets.

Each part shows **Met** or **Missed** against its target. A part that has nothing to measure, or cannot be read at the moment, says so without failing the rest of the report.

The targets used are the service's tier as it read at the end of the month, with the service's own changes over it.

> [!NOTE]
> Measurement runs around the clock. Support hours are shown on the report but not applied yet.

## Permissions

Reading tiers and SLA reports needs `catalog:component:read`. Creating, editing, reordering and archiving tiers, changing a service's targets and setting its RACI need `catalog:component:write`, which Members hold by default. See [Catalog permissions](https://docs.evohub.io/catalog-permissions.md).

## Related

- [Catalog overview](https://docs.evohub.io/catalog-overview.md)
- [Uptime monitoring](https://docs.evohub.io/uptime-overview.md)
- [Alerts and incidents](https://docs.evohub.io/alerts-and-incidents.md)