What this template is for
A service-level objective only works if everyone agrees on the SLI, the target, the window, and the error budget. Most teams treat SLOs as informal slack-channel agreements; that is fine until the first incident burns the budget and product and engineering discover they had different numbers in mind.
This template makes the SLO ratification process explicit: one ticket per proposal, with the exact SLI query, target, window, and error budget written down. Approvers sign off on the ticket. The Status field tracks proposed/active/deprecated so the team’s set of live SLOs is one JQL query away.
When to use it
Use this template:
- Whenever you propose a new SLO
- When changing an existing SLO’s target or window (treat it as a new proposal)
- When deprecating an SLO that no longer represents user experience
Routine SLO measurement and reporting do not need new tickets - they happen against the active SLO definition.
Sub-task breakdown
The 6-month review sub-task is the one that prevents SLO drift. Business reality changes - traffic patterns shift, dependencies move, the product strategy reweights what matters - and a stale SLO is worse than no SLO. STM Issue Templates creates the review sub-task on every new SLO definition automatically, so the review happens on the calendar whether anyone remembers or not.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | SLO proposal - payments-svc checkout availability 99.95% | Yes |
Service (custom) | payments-svc | Yes |
SLI (custom) | Successful HTTP 200 responses on POST /checkout | Yes |
SLO Target (custom) | 99.95% over 28-day rolling window | Yes |
Window (custom) | 28 days rolling | Yes |
Error Budget (custom) | 21m 36s of unavailability per 28 days | Yes |
Measurement Source (custom) | Prometheus rate(http_requests_total{status='200'}) | Yes |
Burn Rate Alerts (custom) | Fast: 2% in 1h. Slow: 10% in 6h. | Yes |
Owning Team | Payments Platform | No |
Approvers | @payments-pm, @sre-lead, @cto | No |
Status (custom) | Proposed / Active / Deprecated | No |
Effective Date | 2026-06-01 | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Draft SLI definition and confirm it is measurable from existing telemetry
- Propose target, window, and error budget based on current performance + business need
- Configure burn-rate alerts (fast + slow)
- Circulate for approval: product owner, SRE lead, exec sponsor
- Once approved, set Status to Active and publish on the team's SLO page
- Schedule a 6-month review of the SLO target
Common questions
What is an SLO in Jira used for?
Treating an SLO as a Jira ticket makes the proposal-and-approval process explicit. The ticket captures the SLI (what is measured), the target (the agreed level), the window (over what period), and the error budget (how much failure is allowed). Approvers sign off on the ticket, and the ratified SLO is the artefact teams build burn-rate alerts against.
How do you choose an SLO target?
Start from current performance, not from aspiration. If you currently deliver 99.9% and would like to deliver 99.99%, set the SLO at 99.9% and use the gap as engineering work. Setting an SLO above current performance burns the error budget on day one and erodes the whole SLO programme's credibility.
Should every service have an SLO?
Every service whose failure is user-visible, yes. Internal-only services usually do not need formal SLOs - they need integration-level SLIs that roll up into the user-facing service's SLO. Over-defining SLOs is a common failure mode; if you cannot describe how the SLO affects an end-user metric, do not create it.
Can you automate SLO definition and review tickets?
Yes - use [STM Issue Templates](/stm/) to create the quarterly review ticket per active SLO with the standard sub-tasks (pull last-quarter actuals, compare against target, recommend keep/raise/lower, get sign-off). The 6-month review sub-task is the one most likely to be forgotten otherwise.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →