Service Health
Access and team ownership
Service Health uses team ownership to scope the numbers people see and route problems to the right Jira project. Environment admins manage access and configuration; members read the rules and investigate their permitted services.
Assign an owner
In Admin → Services, confirm the team responsible for each discovered service. A suggested name or owner is a starting point to check, not evidence that your organisation has agreed on responsibility.
Ownership and access are different. Assigning a team says who looks after a service. Granting app access says who may see it. A service without a team cannot raise Jira tickets.
Who sees which teams?
Environment admins see every team. For other readers, Admin → Access controls who can use the app and whether they see selected teams or every team. You can grant access through users and security groups. Sync access after a group changes.
Team scoping also applies when opening service details or raising a ticket. Sharing a URL does not grant someone access to the underlying data.
Admin and member views
| Action | Who can do it |
|---|---|
| Read health, dependencies and tickets | People with access, within their permitted teams |
| Raise a ticket for a visible API | Readers, when Jira and routing are configured |
| Read how the app counts | Members in Rules; admins in the editors |
| Configure sources, owners, objectives, endpoint grouping and exclusions | Environment admins |
| Manage app access | Environment admins |
Creating or completing a source connection also needs Data Sources permission.
The health measures describe services and teams, rather than individual performance. Ticket views show where the work is, rather than naming who raised it.
Before inviting a team
Confirm that its services have the right owners, its readers have the intended scope, and its Jira project mapping works. Ask a member to open a permitted service and read its rules, so the team understands both what the target is and why it was chosen.