---
title: Ticket triage and closeout
slug: ticket-triage-and-closeout
summary: How to work an SRE queue end to end, from classifying new tickets to closing stale review and blocked piles with evidence.
order: 7
updated: 2026-11-11
status: ready
---

Use this page for the daily queue sweep, or when a backlog of "In Review" and "Blocked" tickets has grown so large that nobody trusts the board. The goal is a queue where every open ticket has an owner, a next step and a reason to exist.

Tooling for reading and updating Jira is in [connecting Jira](./connecting-jira.md). The automated version of this page is in the [automation blueprint](./automation-blueprint.md).

## Classify every new ticket

Give each ticket exactly one label so it lands in the right workflow.

| Label | Typical ticket | Page |
| --- | --- | --- |
| access | "Grant read access to the reporting database" | [access requests](./access-requests-and-least-privilege.md) |
| deploy | "Release version X to production" | [change control](./change-control-in-regulated-environments.md) |
| pipeline | "Move repo to the new CI system" | [pipeline migration](./ci-cd-pipeline-migration.md) |
| monitor | "Alert is noisy" | [alert hygiene](./alert-and-monitor-hygiene.md) |
| security | "Rotate key", "fix public bucket" | [security remediation](./security-baseline-remediation.md) |
| cleanup | "Decommission unused stack" | [decommissioning](./aws-account-and-resource-decommissioning.md) |
| investigation | "Why did X happen?" | [AWS read-only investigation](./aws-read-only-investigation.md) |
| human | Unclear, political, or needs a decision | a person |

- [ ] Missing information: ask one specific question in a comment, move to "Waiting for requester".
- [ ] Duplicate: link and close as duplicate.
- [ ] Not ours: reassign to the owning queue with a one-line reason.

## Close out the review pile with evidence

For each ticket in "In Review" or "Done pending verification":

```mermaid
flowchart TD
  A[Ticket in review] --> B{Acceptance criteria met?}
  B -- yes --> C{Evidence linked? MR, screenshot, command output}
  C -- yes --> D[Close with summary comment]
  C -- no --> E[Gather evidence read-only, then close]
  B -- no --> F{Still wanted?}
  F -- yes --> G[Bounce to In Progress with what's missing]
  F -- no --> H[Close as won't do, with reason]
```

Closeout comment template:

```text
Closing: <one line of what was done>.
Evidence: <MR link> / <pipeline link> / <verification command and result summary>.
Verified in: <env> on <YYYY-MM-DD>.
Follow-ups: <PROJ-123 or "none">.
```

## Unstick the blocked pile

- [ ] Each blocked ticket names its blocker: a person, a ticket, or a decision.
- [ ] Blocked on a person for more than 10 business days: escalate once, in writing, with the specific ask.
- [ ] Blocked on approval: batch similar approvals into one request so the approver decides once.
- [ ] Blocked forever: close as won't do and say so. A ticket that never moves is noise.

## Useful queue queries

```text
assignee = currentUser() AND statusCategory != Done ORDER BY updated ASC
project = PROJ AND status = "In Review" AND updated <= -14d ORDER BY updated ASC
project = PROJ AND status = Blocked ORDER BY created ASC
project = PROJ AND created >= -1d ORDER BY created DESC
project = PROJ AND duedate < now() AND statusCategory != Done
```

## Bulk work safely

- [ ] Draft every comment and transition first, in a file, and have a human review the batch.
- [ ] Post in batches of 20 or fewer and spot-check the first few.
- [ ] Never bulk-close without a per-ticket reason.

## Pitfalls

- Closing on "probably done". Evidence or it stays open.
- Writing secrets, account IDs or customer data in ticket comments. Reference by name.
- Letting an agent post comments directly. Comments go out under a human's name; a human approves them. See [human-in-the-loop approvals](./human-in-the-loop-approvals.md).