Setting up Service Health

An environment admin sets up Service Health by connecting where requests are measured, choosing the initial strictness and starting the first pull. This guide covers both supported sources and the checks to make before trusting the numbers.

Before you start

Open Service Health from the portal's Apps area, then Admin → Setup. You need an Azure Log Analytics workspace containing your Application Insights request data, or OpenObserve containing your OpenTelemetry traces. Connecting or completing a data source also requires permission to manage Data Sources.

The app works from the measurements you send. If a service is not instrumented or its requests are missing from the source, its absence here does not mean it is healthy.

Connect Azure Log Analytics

The connection form explains how to prepare access:

1. Register an application in Microsoft Entra ID. Keep its Directory (tenant) ID and Application (client) ID.
2. Create a client secret. Copy its Value, rather than its ID, and note its expiry date.
3. On the Log Analytics workspace receiving Application Insights data, give that application the Log Analytics Reader role.
4. In Setup, choose Connect Azure Log Analytics or Connect another workspace. Enter the two IDs, secret and Workspace ID from the workspace's Overview.
5. Save the connection and select it.

If an Azure source is already connected, Setup can reuse its service principal. Enter the workspace ID if asked, and make sure that principal can read that workspace. Finish connecting means a source is missing required credentials.

Connect OpenObserve

Choose Connect OpenObserve and supply:

Use a dedicated user with permission to search the required traces. Save and select the source. Both source types feed the same health measures, so the SLO and budget guides apply to both.

Choose strictness and start

Choose Relaxed, Standard or Strict. Standard is selected initially. Each preset supplies targets for the three tiers, and the screen shows what those choices mean. You can change them later in Admin → SLOs.

Press Start Service Health. Setup reads recent history, approximately the last month, and shows progress. The screen suggests allowing around ten minutes for initial statuses; the time depends on your source and how much data it holds.

Check what it found

1. Open Admin → Services. Confirm the suggested display names, owning teams and tiers.
2. Assign a team wherever one is missing. Services without a team cannot raise Jira tickets.
3. Open Admin → Endpoints. Check that paths with IDs form useful API groups rather than thousands of separate names.
4. Review Admin → Exclusions. Decide whether health checks and test endpoints should count.
5. Check the objectives against what your users need.
6. If you use Jira, configure project mappings and tickets.
7. Grant the right people access.

How much detail is kept?

Admin → Connector lets you choose which APIs retain five-minute detail for the last 14 days. The default selects active APIs from recent traffic, slow calls and server errors. Selection uses fixed thresholds, so it does not guarantee detail for every API with an at-risk objective. You can choose every API for broader coverage.

Daily totals and detailed points serve different purposes. A day may have totals even when no five-minute detail was retained, so opening it cannot always identify the time the slowdown began.

When setup does not look right

Last-known statuses can remain visible when a pull stops. Read freshness alongside health, and do not treat an old healthy status as a current check.

Continue with Reading the health screens.