# What is Service Health?

Service Health is Solidafy's app for seeing whether your services answer reliably and quickly enough for the people using them. It reads request measurements from Azure Log Analytics or OpenObserve, checks them against your targets, and helps the owning team find where to act.

You do not need to know reliability terminology to use it. Start with [What is an SLO?](/docs/service-health/slos), then [Error budgets and burn rate](/docs/service-health/error-budgets).

## What does the app do?

1. **Reads your request measurements.** You connect an Azure Log Analytics workspace holding Application Insights data, or an OpenObserve source holding OpenTelemetry traces. The app keeps aggregate counts and durations rather than individual requests or spans.
2. **Checks your objectives.** An objective is a target such as “99% of calls should take no more than 500 milliseconds over the last 28 days.” Speed and success have separate objectives and budgets.
3. **Helps you investigate.** Open a service, find the APIs spending its budget, inspect a bad day, and follow the services or external systems it waits on.
4. **Routes the work.** Assign services to teams and, if you use Jira, send problems to each team's project.

## Who is it for?

Teams use it to decide whether to work on reliability and where to start. Engineering managers use it to see which services need attention and whether the right team owns them. Environment admins connect data, choose targets and control access.

The app reads services and teams. It does not rank people.

## How is it organised?

| Place | What you find there |
| --- | --- |
| Health | Services, Problem APIs and Dependencies, with service and API detail pages |
| Tickets | Problems raised in Jira and their current state |
| Admin | Setup, Services, Endpoints, SLOs, Exclusions, Jira, Connector and Access, for environment admins |
| Rules | The rules members can read in place of the admin editors |
| Help | Short guides on the measures and what to do when something is missing |

Choose your team, open a service, then open an API to move from the broad view to the calls behind it. [Reading the health screens](/docs/service-health/reading-health) explains the figures and status words.

## A first investigation

Suppose Checkout is at risk. Open it and check which budget is under pressure. If its speed budget is falling, open **Who spent it**, then the API responsible for the largest share. Open the day the budget dropped and check the five-minute detail, when available. Read **What it waits on** to see whether the API became slow itself or while calling something else.

Agree on an action with the owning team. A budget is a way to decide priorities, rather than a score to make green by changing the target.

## Where do I start?

- **Setting up:** follow [Setting up Service Health](/docs/service-health/setup), then confirm service owners and tiers.
- **Learning the measures:** read [SLOs](/docs/service-health/slos), [error budgets](/docs/service-health/error-budgets) and [latency percentiles](/docs/service-health/latency).
- **Investigating:** use [Reading health](/docs/service-health/reading-health) and [Dependencies and waits](/docs/service-health/dependencies).
- **Changing rules:** read [Targets and inheritance](/docs/service-health/objectives) and [Endpoints and exclusions](/docs/service-health/endpoints-and-exclusions).
- **Following up:** configure [Alerts and Jira tickets](/docs/service-health/alerts-and-tickets) and [Access](/docs/service-health/access).
- **Looking up a word:** use the [glossary](/docs/service-health/glossary).

## The SRE background

SRE means site reliability engineering. Google's [SRE Workbook](https://sre.google/workbook/table-of-contents/) explains the practices behind objectives and budgets. Our concept guides link to the relevant chapters and distinguish those practices from Service Health's particular rules.