What this template is for
Most production incidents from new services trace back to one of the same five gaps: missing SLO, missing runbook, missing alerts, missing security review, or missing on-call coverage. This template makes every one of those gaps a required sub-task on the onboarding ticket so a service cannot quietly skip the operational basics.
The Production-Readiness Tier field keeps the checklist proportionate. A Tier 1 user-facing service walks the full list; a Tier 3 internal tool walks a subset.
When to use it
Use this template:
- For every new service before it carries production traffic
- When an existing service is being promoted in tier (Tier 2 to Tier 1, for example)
- After a major rewrite or topology change - re-run the relevant subset of the checklist
Do not use it for routine deploys or feature additions on an existing service - those have their own templates.
Sub-task breakdown
The sub-tasks above are the production-readiness contract. STM Issue Templates lays them down automatically per tier, so the readiness review meeting becomes a walkthrough of an already-tracked checklist rather than a brainstorm of what should have been done. The go-live gate is one JQL query: open sub-tasks on this onboarding ticket.
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 | Onboard recommendations-svc to production | Yes |
Service Name (custom) | recommendations-svc | Yes |
Owning Team | ML Platform | Yes |
Tech Lead | @alex.chen | Yes |
Production-Readiness Tier (custom) | Tier 1 (user-facing) / Tier 2 / Tier 3 | Yes |
SLOs Defined (custom) | Yes - PROJ-1430 | Yes |
Runbook URL (custom) | RB-219 | Yes |
Dashboards URL (custom) | https://grafana.example.com/d/reco | Yes |
On-Call Rotation (custom) | ml-platform-primary | Yes |
Security Review (custom) | Passed 2026-05-15 | No |
Cost Model (custom) | Tagged; expected $850/month at launch | No |
Go-Live Date | 2026-06-10 | 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.
- Define SLOs for the service (link SLO definition ticket)
- Write runbook for at least the top three failure modes
- Wire up monitoring, logging, and tracing with standard labels
- Configure alerts and burn-rate rules; test that they page correctly
- Complete security review (threat model, dependency scan, secrets handling)
- Schedule a chaos drill or game day before go-live
- Add to on-call rotation and confirm rotation tool routes alerts correctly
- Production-readiness review meeting and sign-off
Common questions
What is a service onboarding ticket in Jira?
It is the production-readiness checklist for a new service joining the platform - SLOs, runbooks, monitoring, alerts, security review, on-call rotation. The ticket is the gate: the service does not join the rotation until every sub-task is signed off. This protects both the service owners and the wider on-call from a service going live without the operational basics.
What is production-readiness?
Production-readiness is the set of operational guarantees a service must meet before it carries production traffic - measurable SLOs, written runbooks, working monitoring, tested alerting, completed security review, and an on-call rotation. A service that fails any of these is not production-ready regardless of how stable the code itself is.
How do you tier services for onboarding?
Tiering reflects blast radius and user impact. Tier 1 is user-facing or revenue-critical and gets the full readiness review. Tier 2 is internal-facing or batch and may use a lighter checklist. Tier 3 is experimental or internal-tools and follows a minimum subset (basic monitoring and ownership). Tiering keeps the readiness review proportionate to risk.
Should onboarding sub-tasks be auto-created?
Yes - the checklist is long and skipping a sub-task is the most common cause of post-launch incidents. [STM Issue Templates](/stm/) can lay down the production-readiness sub-task set on every new onboarding ticket, scoped by tier. The reviewer at the readiness meeting walks the sub-tasks; nothing reaches production with a sub-task still open.
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 →