Service Health
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?, then Error budgets and burn rate.
What does the app do?
- 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.
- 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.
- 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.
- 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 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, then confirm service owners and tiers.
- Learning the measures: read SLOs, error budgets and latency percentiles.
- Investigating: use Reading health and Dependencies and waits.
- Changing rules: read Targets and inheritance and Endpoints and exclusions.
- Following up: configure Alerts and Jira tickets and Access.
- Looking up a word: use the glossary.
The SRE background
SRE means site reliability engineering. Google's SRE Workbook 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.