Reporting on JSM Queues and SLAs from the CLI

atlassian-cli is an independent, community open-source project, not affiliated with, endorsed by, or sponsored by Atlassian, and is not Atlassian's official CLI (acli). Product names are used only to identify compatibility.

Why report on JSM from the CLI

JSM SLA reporting from the command line means pulling queue contents and SLA timers with a handful of atlassian-cli commands, then shaping them into a report with jq instead of clicking through the Jira Service Management UI. It is the fastest way to answer questions like "which open requests are about to breach time-to-resolution?" without building a dashboard or paying for a reporting add-on.

The built-in JSM reports are fine for a glance, but they are slow to filter, hard to schedule, and impossible to diff. When you need the same breach report every morning, or want to feed SLA data into a spreadsheet, a Slack post, or a CI gate, a scriptable pipeline wins. The CLI exposes the same data the Jira Service Management Cloud REST API returns, so anything Atlassian tracks (queue membership, SLA cycles, remaining time, breach flags) is available as JSON you can slice however you like.

A quick note on what this tool is. atlassian-cli is an independent, community open-source project. It is not Atlassian's official CLI (acli) and is not affiliated with Atlassian. Use the official acli for first-party vendor support; use atlassian-cli if you want a single free binary spanning Jira, Confluence, Bitbucket, and JSM with JSON output built for pipelines. More on that difference below.

Find your service desk and queue IDs

Every JSM reporting command hangs off two numeric IDs: the service desk ID and, for queues, the queue ID. These are not the project key you see in the portal, so start by listing them.

# List all service desks you can access
atlassian-cli jsm service-desk list --limit 25

# Inspect one service desk (here, ID 10)
atlassian-cli jsm service-desk get 10

Once you have a service desk ID, list its queues. Each queue is a saved JQL view (for example "Unassigned", "Waiting for support", or "Breaching soon") that agents work from.

# List the queues in service desk 10
atlassian-cli jsm queue list 10

# Get one queue's definition, including its issue count
atlassian-cli jsm queue get 10 5

The queue get output includes the queue name and the number of issues currently in it, which is already a useful top-line metric. To pull the actual tickets, you move on to queue issues.

Pull a queue's contents

The jsm queue issues command returns the requests inside a queue. The two positional arguments are the service desk ID and the queue ID, in that order.

# First 25 issues in queue 5 of service desk 10
atlassian-cli jsm queue issues 10 5 --limit 25

# Same, as CSV, written to a file for a spreadsheet
atlassian-cli jsm queue issues 10 5 --format csv > queue.csv

# As JSON, piped into jq to grab key, summary, and status
atlassian-cli jsm queue issues 10 5 --format json \
  | jq '.[] | {key: .key, summary: .fields.summary, status: .fields.status.name}'

Because a queue is just a JQL view, this is the cleanest way to snapshot "what is open right now" for a support team. Export it to CSV for a weekly stakeholder update, or keep it as JSON so you can join it against SLA data in the next step. The --limit flag controls page size; the CLI paginates for you, so raising it fetches more issues per call rather than truncating results.

One convenience worth knowing: adding the global --envelope flag wraps list output as {"data": [...], "count": N}. That makes downstream parsing easier when a script needs the total count without a second jq length pass.

Pull SLA data per request

Queues tell you what is open. SLAs tell you what is late. In JSM, each request carries one or more SLA metrics (commonly "Time to first response" and "Time to resolution"), and each metric has an ongoing cycle with a remaining time and a breach flag. The CLI exposes this per request.

# All SLA metrics on a single request
atlassian-cli jsm sla list SD-123

# One specific metric by its SLA ID
atlassian-cli jsm sla get SD-123 --sla-id time-to-resolution

# SLA metrics as JSON for filtering
atlassian-cli jsm sla list SD-123 --format json

When you pass --format json, the output mirrors the shape of the Jira Service Management Cloud REST API. Each metric object carries an ongoingCycle with a breached boolean and a remainingTime object (with both a millisecond value and a human-friendly string), plus completedCycles for metrics that have already finished. Because the field names match Atlassian's own API documentation, any jq expression you write here is portable and easy to verify.

To surface just the breached metrics on one request:

atlassian-cli jsm sla list SD-123 --format json \
  | jq '.[] | select(.ongoingCycle.breached == true) | .name'

Build a breach report with jq

Now combine the two. The pattern is: list a queue's keys, loop over them, call jsm sla list for each, and keep only the breached (or soon-to-breach) metrics. The result is a compact report of "which tickets are behind, and on which clock."

#!/bin/bash
# breach-report.sh -- flag breached SLAs in a JSM queue
set -euo pipefail

SERVICE_DESK="10"
QUEUE="5"
PROFILE="prod"

# 1. Collect the request keys currently in the queue
keys=$(atlassian-cli jsm queue issues "$SERVICE_DESK" "$QUEUE" \
  --profile "$PROFILE" --format json --limit 100 \
  | jq -r '.[].key')

# 2. For each key, print any breached SLA metric
for key in $keys; do
  atlassian-cli jsm sla list "$key" --profile "$PROFILE" --format json \
    | jq -r --arg k "$key" \
      '.[] | select(.ongoingCycle.breached == true)
        | "\($k)\t\(.name)\tBREACHED"'
done

That prints a tab-separated line per breached metric, for example SD-118 Time to resolution BREACHED. Redirect it to a file, pipe it into column -t for readable output, or wrap it in a header row and save it as CSV. To catch tickets that are close but not yet breached, swap the select for a remaining-time threshold:

# Flag metrics with under 60 minutes remaining (3,600,000 ms)
jq -r --arg k "$key" \
  '.[]
    | select(.ongoingCycle != null)
    | select(.ongoingCycle.remainingTime.millis < 3600000)
    | "\($k)\t\(.name)\t\(.ongoingCycle.remainingTime.friendly) left"'

This is the whole point of doing JSM SLA reporting from the terminal: the filtering logic lives in a script you own, not in a saved view you have to recreate every time a manager asks a slightly different question. Change one number and you have a new report.

Command reference at a glance

Here is what each JSM reporting command returns and the IDs it needs. Every command accepts the global --format, --profile, and --limit flags.

If you need requests that are not scoped to a queue (for example, everything a single customer raised), reach for jsm request list --servicedesk-id 10 instead of a queue. The request management guide covers those workflows in depth.

Schedule it and post to Slack

A report you have to remember to run is a report you will forget. Wrap the breach script in cron so it lands in your inbox or a channel every morning. The commands themselves are non-interactive once a profile is configured, so nothing blocks in an automated context.

# crontab -e: run the breach report every weekday at 08:30
30 8 * * 1-5 /opt/reports/breach-report.sh > /opt/reports/out/breach-$(date +\%F).tsv 2>&1

To push results into Slack, count the breached lines and only post when there is something to say:

report=$(/opt/reports/breach-report.sh)
count=$(printf '%s\n' "$report" | grep -c BREACHED || true)

if [ "$count" -gt 0 ]; then
  curl -s -X POST "$SLACK_WEBHOOK" \
    -H 'Content-type: application/json' \
    -d "{\"text\": \"$count breached SLA(s) in the support queue this morning.\"}"
fi

Set up a dedicated auth profile for the machine that runs this so it uses a service account rather than your personal token. See the authentication docs for profile setup, and the command reference for every flag mentioned here.

How this differs from acli

Atlassian ships its own official command-line tool, acli. It is the first-party option and comes with vendor support. atlassian-cli is a separate, independent, MIT-licensed open-source project that is not affiliated with, endorsed by, or maintained by Atlassian. The two are not the same binary and are not interchangeable in configuration.

Pick based on what you need. If you want official support and are comfortable inside Atlassian's own tooling, use acli. If you want one free binary that covers Jira, Confluence, Bitbucket, and JSM with consistent --format json output designed for jq and shell pipelines like the ones above, atlassian-cli is built for exactly that. Product names such as Jira Service Management appear here only to describe compatibility, not affiliation.

FAQ

Related Resources