Jira and CodeWords: the reporting Jira does badly

Jira has automation rules, and they are capable: triggered by issue events, conditioned on fields, acting across projects on the higher tiers. For moving issues, setting fields, and keeping linked work in step, use them.

Where Jira consistently disappoints is telling you how work actually flows. Its built-in reports count issues and measure sprints. The questions teams actually want answered — how long does work take from start to done, where does it wait, what is stuck and for how long — require reading the issue changelog and doing the arithmetic yourself.

What we'll cover

• Counting against measuring flow
• Where Jira automation rules stop
• What the Jira API reaches
• Connecting it to CodeWords
• Eight automations worth building
• Computing cycle time honestly
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

Counting against measuring flow

Counting is how many issues are in each status, how many were closed this sprint, how many are assigned to whom. Jira does this natively and it is nearly useless for improving anything, because a count tells you where things are and not how they got there or how long it took.

Measuring flow is how long an issue spends in each state, where the queue forms, how much of the elapsed time is work and how much is waiting, and whether any of that is changing. This requires the changelog — the record of every status transition with its timestamp — and Jira does not report on it well.

The distinction matters because the flow numbers are the ones that change behaviour. A team told they closed eighteen issues learns nothing. A team shown that work waits an average of four days in code review and eleven hours everywhere else knows exactly what to fix.

Where Jira automation rules stop

Rule execution limits apply by plan, and a busy project with several rules reaches them.

Cross-project reasoning is limited, and global rules are a higher-tier feature.

External data is not available. A rule cannot ask your deployment system whether this was released, or your support tool how many customers reported it.

Historical analysis is not what they are for. Rules react to events. Computing a distribution over the last quarter is a different shape of work entirely.

Use rules for what they do well — transitions, field updates, linked issue maintenance — and reach outside for anything analytical or anything needing a system Jira cannot see.

What the Jira API reaches

Issues can be created, read, updated, transitioned, and searched with JQL, which is the query language everything here depends on.

Changelog on each issue records every field change with a timestamp, including status transitions. This is the raw material for all flow measurement and the reason this integration is worth building.

Projects, boards, and sprints can be read, including sprint start and end dates.

Worklogs can be read and written for anyone tracking time.

Comments can be read and added, which is where automated context belongs.

Issue links describe relationships between issues, which matters for anything tracing a bug to a release.

Webhooks fire on issue events, and Jira's own automation rules can call an external URL, which is the tidy way to hand specific cases outward.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which projects, which question, and where the answer goes.
3. Authorize the connection with an API token scoped to what the automation needs, read-only where it only reads.
4. Describe the exceptions: an issue that skipped a status, one that moved backwards, one that has been open since before your history window.
5. Run it against a completed quarter where you already have a sense of the answer, and see whether it agrees.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Eight automations worth building

Cycle time by state. How long work spends in each status, as a distribution rather than an average. The most useful number any engineering team can have and the one Jira makes hardest to get.

Queue detection. Which states accumulate work, and whether that is getting worse. Waiting is invisible in a count and obvious in a flow measurement.

Aged work-in-progress. Issues in progress longer than your normal range, reported with how long and to whom. Every board has a few and nobody closes them out.

Blocked-issue chasing. Issues flagged blocked, with how long they have been blocked and who was supposed to unblock them. Blocked issues persist because the flag is set and then nobody revisits it.

Release correlation. What shipped in each release, traced from deployment back through issues, so the question of what changed has an answer.

Cross-system enrichment. Write support ticket volume, customer impact, or revenue exposure onto issues, so prioritisation uses more than an opinion about severity.

Sprint reality reporting. What was committed, what was added mid-sprint, what carried over, and how that compares to previous sprints. Scope added mid-sprint is the thing sprint reports hide.

Hygiene reporting. Issues with no assignee, no estimate, no description, or in a state nobody uses, reported for tidying rather than fixed automatically.

Computing cycle time honestly

Worth doing carefully, because it is easy to produce a number that is precise and wrong.

Use the changelog, not created and resolved dates. The gap between creation and resolution includes however long an issue sat in the backlog before anyone started, which is usually most of it and tells you nothing about how fast your team works.

Define start and end explicitly. Start is usually the first transition into an in-progress state; end is the first transition into done. Write the definition down, because two people will otherwise pick differently and produce different numbers from identical data.

Handle backwards transitions. Issues move back to in-progress after review, and an automation summing all time in that state double-counts unless you decide what reopening means.

Report the distribution, not the mean. Cycle time is skewed by a few very old items, and a mean flatters or alarms depending on which. The median and an upper percentile describe reality far better.

Use working hours where it matters. For anything compared against a service commitment, elapsed time over a weekend is not work time.

Exclude what you have decided to exclude, visibly. If you drop issues that were cancelled, say so on the report. Silent exclusions are how two people produce different figures and neither can explain why.

Building it so it survives

Make it safe to run twice. Webhooks retry. An automation commenting on an issue should check whether it already commented, or issues accumulate identical notes.

Never let it transition issues unsupervised unless that is specifically its purpose and somebody agreed. Status is a statement about reality that people rely on.

Paginate properly. JQL results are paginated, and an automation reading the first page computes its distribution from a flattering sample.

Read-only where possible. Nearly all the reporting here needs no write access at all.

Report to a board or channel, not to individuals. Flow metrics are a team conversation. Sent to individuals they read as performance monitoring and change what people record rather than how they work.

Limits worth knowing about

Rate limits apply and vary by plan and deployment, so bulk changelog reading across many issues needs pacing.

Changelog is paginated per issue on large issues, which is easy to miss and produces silently incomplete histories.

JQL has a result cap per request, so anything analytical should paginate deliberately.

Cloud and Data Center APIs differ, so material for one may not apply to the other.

Custom field IDs vary per instance. An automation hard-coding a field ID from one Jira will not work against another, which catches people moving a working automation between environments.

What to build first

Cycle time by state, read-only, over the last quarter. It needs no write access, it usually surprises the team, and it identifies the queue that is actually slowing you down — which is almost never the one people assume.

Two habits make the difference. Run it against a period the team remembers and check the numbers against their intuition, since disagreements usually reveal a definition problem rather than a data problem. And publish the definition of start and end alongside the numbers, because the first question will be how you measured it.

Frequently asked questions

Why not use Jira's built-in reports?

Use them for what they cover, which is sprint progress and issue counts. They do not report on time in state, which is where the actionable information lives, and reconstructing it from a control chart is harder than computing it directly from the changelog.

Should automation transition issues?

For mechanical transitions tied to an external event — a merged pull request moving an issue to review — yes, and that is usually better done with Jira's own automation rules anyway. Anything requiring judgement about whether work is genuinely done should stay with a person.

How do I compute cycle time correctly?

From the changelog, measuring transitions between explicitly defined start and end states, handling backwards moves deliberately, and reporting a median and an upper percentile rather than a mean. Publish the definition with the number.

Can it pull in customer impact?

Yes, and it is one of the better reasons to automate here. Writing support ticket counts or affected customer numbers onto issues turns prioritisation from a debate about severity into a comparison of actual impact.

What permissions does it need?

Read-only for all the reporting, which is most of the value. Write access only for the specific automation that comments or enriches, scoped to the projects involved.

Why do my numbers differ from someone else's?

Almost always a definition difference — what counts as started, what counts as done, whether cancelled issues are included, whether weekends count. This is why publishing the definition matters more than the number itself.

Can Jira's own rules call my automation?

Yes, through a web request action, which is the tidiest pattern: let Jira decide which issues need external handling using its own conditions, and hand only those outward rather than polling everything.

How much history should the analysis cover?

A quarter for cycle time, which is long enough to be stable and short enough to reflect how the team works now. A year tells you about a team that no longer exists, since the people, the process, and the product have all changed.

What about work that never enters Jira?

It will not appear, which is worth knowing before presenting the numbers as complete. Where a meaningful share of work is handled outside the tracker, the flow metrics describe a subset, and saying so is more useful than a confident figure everybody privately discounts.

Should flow metrics be shown to individuals?

Show them to the team. Cycle time is a property of a system — handoffs, queues, review capacity — rather than of a person, and reporting it individually reliably changes how people record work rather than how the work flows.

How do I handle issues that sat in the backlog for months?

Exclude backlog time from cycle time by measuring from the first in-progress transition, and report the wait separately if it matters. Combining them produces a number dominated by prioritisation decisions rather than by how quickly work gets done once started.

What is the fastest way to make the numbers credible?

Publish the definition alongside them and show the distribution rather than an average. Most disputes about flow metrics are disputes about method rather than about the data, and pre-empting that turns an argument into a conversation about what to fix.

Related reading

• Monday.com and CodeWords
• GitHub and CodeWords
• CodeWords integrations and templates