Service Health
Alerts and Jira tickets
An alert calls attention to a budget problem; a ticket gives the owning team work to follow up. This guide explains what Service Health detects, which actions your settings allow and how Jira routing avoids duplicate tickets.
Read Error budgets and burn rate first if burn rate is unfamiliar.
What triggers attention?
The app evaluates speed and success separately. For each API and objective, it selects the most urgent matching rule:
| Rule | Condition |
|---|---|
| Budget used up | The objective is breached, with no budget left |
| Fast burn | The last hour's bad-call share is more than 14.4 times the allowed share |
| Slow burn | The last six hours' bad-call share is more than 6 times the allowed share |
With a 99% speed target, the allowance is 1%. A fast burn means more than 14.4% slow calls in the last hour; a slow burn means more than 6% over the last six hours. These rules use recent measurements, which must be available. No usable health reading means no objective alert.
Budget used up takes precedence. Fast burn is considered before slow burn where the tier allows it. The app does not need both an hour and six hours to breach their thresholds together.
Which action does a tier allow?
In Admin → SLOs, each tier's When it burns setting chooses whether to alert and ticket, ticket only, or show the problem without raising anything.
Fast burn applies to tiers set to Alert the team, then raise a ticket. Ticket-only tiers still detect slow burn and exhausted budgets. Choosing Nothing, show it only suppresses these actions while keeping health visible.
Automatic Jira creation is for slow burn and budget used up, and needs both Jira switches below. A fast-burn alert alone does not automatically create a Jira ticket.
Note: Google's workbook describes several alerting approaches, including paired long and short windows. The table above describes Service Health's rules. Read Alerting on SLOs for the wider design tradeoffs.
Set up Jira routing
In Admin → Jira:
- Enable Raise tickets in Jira.
- Map each owning team to a project available from your connected Jira site.
- Optionally select a Fallback project for teams without a mapping.
- If you want automatic tickets, enable Raise one on its own when a budget burns steadily or runs out. The tier's action must also allow tickets.
A service needs an owning team. No team means no ticket, even with a fallback project. A team without either a project mapping or fallback also gets no ticket.
Raise and follow a ticket
Readers can raise tickets for APIs they can see, when Jira is enabled and routing is available. The ticket carries the API and its latest measurements. Open Tickets to follow the raised problems and their state.
The app keeps one ticket for each service, API and problem-state category. Raising the same category again updates the existing ticket with the latest numbers rather than creating another; repeated comments for the same day are deduplicated. A different category can have a different ticket.
No ticket appeared
Check the service owner, the team's project or fallback, Jira connection, both ticket switches and the tier's burn action. If you expected automatic creation from fast burn alone, that rule alerts rather than auto-creating a ticket. Excluded, unrouted or ungraded APIs do not raise objective alerts.
Agree what happens after an alert
Choose who investigates, what counts as urgent and when reliability work takes priority. Google's Example error budget policy is a useful discussion starting point. Its release rules are an example policy, not automatic behaviour in Service Health.