Connect Jira, Get a Toil Analysis Within the Hour
This is part four of our Connection Value series, which walks through what actually happens, concretely and on a clock, after you connect each kind of tool to CloudThinker. Part two covered cloud accounts and dollar findings; part three covered repos and PR review. This one covers your ticket queue: Jira, ServiceNow and similar ITSM tools.
The pitch is simple. Your ticket history is the most honest record your team has of where engineer time actually goes, and almost nobody reads it. Within an hour of connecting, CloudThinker reads all of it and hands you a report that says, in hours and categories, what your interrupts are costing you and which ones a machine could be handling.
Why toil never wins the prioritization argument
Every platform team knows it has toil. Few can say how much, and that's why it loses to feature work in every planning meeting. The reasons are structural:
- Components and labels lie. Tickets get filed under whatever component the reporter guessed. "Disk full on payments-db" and "/var at 95% on worker-7" are the same problem filed three different ways. The categories your Jira claims aren't the categories your work forms.
- Each ticket is small. A disk cleanup takes forty minutes. Nobody escalates a forty-minute task. Thirty-one of them a month is most of a week, and it's invisible one ticket at a time.
- Reading history is nobody's job. Pulling six months of tickets and reading them all is an afternoon of JQL and a week of reading. It's the first thing cut when the sprint is full.
- The knowledge is in resolution comments. How the problem was actually fixed lives in free-text comments, not in fields. Dashboards that count tickets by field never see it.
The manual version starts with a query like this:
project = OPS AND created >= -180d AND resolution IS NOT EMPTY ORDER BY created DESC
Or, to pull the raw data for a spreadsheet, the Jira Cloud REST API:
curl -s -u you@example.com:$JIRA_API_TOKEN -G \
"https://your-site.atlassian.net/rest/api/3/search/jql" \
--data-urlencode "jql=project = OPS AND created >= -180d" \
--data-urlencode "fields=summary,labels,status,created,resolutiondate" \
--data-urlencode "maxResults=100"
That gets you the rows. Clustering a thousand of them by what they really are, estimating the hours, and checking which ones a runbook already covers is the part nobody has time for.
The first hour: a Toil Analysis from your own ticket history
01Ticket history
ITSM
- Jira6 to 12 months of tickets
ServiceNowIncidents and requests- What it readsTitles, labels, comments, timestamps
Read-only API token
02Analysis
CloudThinker
- ClusterCategories the tickets really form
- EstimateHours from status timestamps
- MatchRunbooks and automations that fit
- RankAutomatable today or not
No writes in the first hour
03Where it lands
The report
ConfluenceOne-click publish- PDFFor the headcount conversation
ChatQuestions about any row
Built to be forwarded
The connection itself is the standard flow: an API token scoped read-only, no write access at connection time, following the connection guide. Once connected, the agent pulls 6 to 12 months of ticket history (titles, descriptions, labels, resolution comments, timestamps) and clusters it into recurring categories. Not the categories your Jira components claim, but the categories the tickets actually form when you read all of them, which nobody on your team has time to do.
Within the hour you get a Toil Analysis report: your top 10 recurring ticket categories, the estimated engineer-hours each burned over the period, and which categories are automatable today. The hours come from time-in-status and resolution timestamps, so they're an estimate, but one grounded in your own data rather than an industry benchmark.
Numbers below are illustrative: a composite of what a first analysis tends to surface for a platform team fielding ~200 tickets a month. Yours will differ, which is rather the point.
| Ticket category | Tickets/month | Est. hours/month | Automatable today? |
|---|---|---|---|
| Disk space / volume full alerts | 31 | ~26 | Yes |
| Access requests (IAM, repo, VPN) | 24 | ~18 | Partially, with approval |
| Certificate expiry / renewal | 9 | ~11 | Yes, can run on its own |
| Service restart requests | 14 | ~9 | Yes, with approval |
| "Environment is slow" investigations | 12 | ~21 | Enrichment only |
| Failed deployment rollbacks | 7 | ~10 | Partially, with approval |
| Database connection-limit incidents | 6 | ~8 | Enrichment only |
| Stale-branch / repo cleanup | 8 | ~4 | Yes, can run on its own |
| Monitoring false-positive triage | 19 | ~7 | Yes, as proposals |
| Onboarding / offboarding checklists | 5 | ~12 | Partially, with approval |
That's roughly 126 engineer-hours a month, most of a full-time engineer, going to work that is by definition recurring. And notice the shape: the top rows aren't hard problems. Disk-full tickets and certificate renewals are solved problems that keep getting re-solved by hand, one interrupt at a time.
The report exports to PDF and Confluence. That's deliberate. "We spend 126 hours a month on ten categories of repeat work, and here's which ones we can automate" is the kind of one-pager that gets headcount conversations and automation budgets unstuck. Forward it to your manager; that's what it's for.
One category, looked at closely
A row like "Disk space / volume full, 31 tickets" can mean very different things, and the fix depends on which. There are three common readings:
- Real capacity growth. Data volumes are growing and disks are undersized. Tickets spread across many hosts, and each host fills more slowly than the last time.
- One noisy service. A single application writes too much (debug logging left on, a temp directory nobody cleans). Most tickets name the same few hosts, and the resolution comments say "cleared logs" or "deleted tmp".
- A broken housekeeping job. Log rotation or a cleanup cron stopped running. Tickets started on a specific date and recur on a steady cadence afterwards.
Each reading predicts something you can check in the ticket data itself. Ask CloudThinker to break the row down: which hosts appear, how often per host, when the cluster began, and what the resolution comments actually say. If 24 of the 31 tickets name the same three hosts and the comments all say "rotated logs manually," that's the second or third reading, and the right fix is the rotation job, not bigger disks or a faster cleanup script. With an observability connection, the same check can confirm it from disk-usage graphs. Knowing which reading the evidence supports means the automation you build targets the cause.
After the report: the ladder up
The Toil Analysis is the first hour. What follows is a sequence of capabilities you turn on one at a time, each governed by Auto Mode, so you decide what runs on its own and what waits for approval, with RBAC and a full audit trail underneath.
01Hour 1
Toil analysis
Top recurring categories, hours burned, what is automatable.
02Rung 1
Auto-triage
Severity, labels, routing and a runbook link on arrival.
03Rung 2
Enrichment
Logs, metrics and the nearest deploy, posted on the ticket.
04Rung 3
Auto-resolve
Known classes with a verified runbook, fixed and closed.
05Rung 4
Learn
Postmortem and a new runbook drafted from what really happened.
Auto-triage of new tickets
First rung: every new ticket gets classified as it arrives, with severity, labels, routing to the right team, and a link to the most relevant runbook if one exists. The goal is that the large majority of tickets never need a human triager. Crucially, that rate is measured and shown, not asserted: the dashboard tracks what fraction of tickets were triaged without human correction, so you can watch it climb (or catch it when a new ticket pattern confuses it) rather than take it on faith. Most teams have a human confirm each classification for the first week or two, then let triage run on its own once the correction rate is boringly low.
If you're drowning in alert-driven tickets specifically, this pairs with the approach in our alert fatigue and triage post: same discipline, applied at the ticket layer.
Investigation enrichment on incident tickets
Second rung: when an incident-type ticket is created, Resolve posts an investigation comment on it within about five minutes: relevant log excerpts, the metrics that moved and, if you've connected a repo (part three), the nearest deploy to the incident window. The engineer who picks up the ticket starts from evidence instead of a blank page. This is where connections compound: the Jira connection alone gets you the comment; Jira plus observability plus a repo gets you a comment with a suspect. Teams measuring MTTR usually see the first movement here, because the minutes lost to "let me go pull the logs" happen on every single incident.
Auto-resolution of known classes
Third rung, and the one that actually deletes rows from the toil table: for ticket categories with a verified runbook (disk full, certificate renewal, service restart), the agent carries out the fix, closes the ticket with a resolution note, and logs every action taken. Where you want approval, the fix is staged and a named person clicks execute. Where you've let it run on its own, the 2 a.m. disk-full ticket is opened, resolved and closed before anyone's phone lights up, and the audit trail shows exactly what was run and when.
The post-resolution loop
Fourth rung: when an incident closes, the agent drafts a postmortem from the actual investigation and resolution record (timeline, evidence, actions taken), plus a proposed new runbook or Skill distilled from how the incident was really resolved, not how someone remembered it a week later. Skills are portable SKILL.md files, and any automation built from one dry-runs in a sandbox before it touches anything real. One click publishes the postmortem and runbook to Confluence. This is the loop that matters over months: every resolved incident makes the next occurrence cheaper, and the toil table from your first hour keeps shrinking for reasons you can point at. (More on building this practice in runbook automation.)
Why this beats the traditional approach
| Manual toil review | Jira dashboards | CloudThinker toil analysis | |
|---|---|---|---|
| How often it happens | Once, when someone has a week | Always on, but shallow | Within the hour, then continuous |
| Categories | Whatever the reviewer notices | Components and labels as filed | Clusters the tickets actually form |
| Hours spent | Guessed | Not shown | Estimated from status timestamps |
| Root cause per category | Sometimes, by reading comments | Never | Drill down by host and comment, in chat |
| Next step | A slide | A chart | Matching runbook or automation, gated by Auto Mode |
| Shrinks over time | Only if someone acts | No | Each resolution feeds a new runbook |
The deeper difference is that the analysis reads the text as well as the fields. Dashboards count what was filed; the toil lives in what was written in the resolution comments. Reading every one of those is the work nobody had time for, and it's the work that tells you which automation to build.
What it won't do, and what read-only can't see
Worth stating plainly, because an agent with write access to your ticket system and your infrastructure deserves scrutiny:
- Auto-resolve runs only on categories with a verified runbook, and only where you've turned it on for that category. There's no general "let the AI close tickets" switch. A category without a verified runbook always waits for a person, no matter what else you've enabled.
- Everything else waits for a person. Novel incidents, ambiguous requests, anything outside a known class: the agent enriches and proposes; a person decides.
- The connection starts read-only, and read-only means read-only. In the first hour the agent can analyze history and generate the report, but it can't comment on tickets, change labels or transition anything. Each write capability (commenting, triaging, resolving) is a separate opt-in. It also can't see what you don't connect: without an observability connection, enrichment comments are thinner; without a repo, there's no nearest-deploy correlation.
- The audit trail shows every action taken on every ticket: what was read, what was proposed, who approved, what was executed. When your manager asks "what exactly did the agent do last month," that's a query, not an archaeology project.
The right mental model: the first hour is a free read of your own history. Every rung after that is a decision you make, per category, with the evidence in front of you.
Getting started
Connect Jira or ServiceNow with a read-only token, then ask:
"Analyze the last six months of tickets in the OPS project. Show the top ten recurring categories with estimated hours, and which ones are automatable today."
"For the disk-full category, which hosts appear most often and what do the resolution comments say was done?"
"Draft a runbook for certificate renewals based on how we resolved them last quarter. Propose only, change nothing."
Related reading
- Part one: the connection value ladder
- Part seven: the compounding effect
- Runbook automation
- Auto Mode: decide what runs on its own
Read your own ticket history first
Most teams have never actually measured their toil. They feel it but can't put a number on it, so it never wins the prioritization argument. One read-only connection and one hour later, you have the number, from your own tickets, in a report built to be forwarded.
Try CloudThinker free (100 premium credits, no card required) and follow the connection guide to connect Jira or ServiceNow and see your own toil table within the hour. Next in the series: connect PagerDuty and get an alert noise audit.