DEV Community: Alina Chyzh

How to Query Jira Worklog Data with JQL And Where JQL Falls Short

Alina Chyzh — Tue, 28 Apr 2026 13:32:47 +0000

Jira stores every worklog your team ever submits. Time spent, date, author, comment — it's all in there. The frustrating part is that most of this data is surprisingly hard to surface through the UI.

If you've ever tried to answer "how much time did the team log last week, grouped by user?" using native Jira tools, you've probably ended up in one of these places:

An Issue Navigator export that gives you issue-level time, not user-level totals
A spreadsheet with =SUMIF formulas pulling from a CSV dump
A dashboard gadget that kind of shows what you need but not quite

This post covers what JQL can and can't do with worklog data, some queries worth having in your toolkit, and where the Jira REST API becomes a better approach than JQL for anything more complex.

What JQL actually lets you filter on for worklogs

JQL has four worklog-related fields you can use in queries:

worklogAuthor
worklogComment
worklogDate
worklogDate >= "YYYY-MM-DD"

That's it. No worklogHours, no totalTimeSpent filter, no grouping by user. JQL can find which issues a person logged time on, within a date range — but it can't sum that time, filter by amount, or aggregate across users.

Here are the queries I find myself writing most often:

All issues where a specific user logged time this month:

worklogAuthor = "user@company.com" AND worklogDate >= startOfMonth()

All issues where anyone on the team logged time this sprint:

worklogAuthor in membersOf("team-name") AND worklogDate >= -14d AND sprint in openSprints()

Issues logged by the current user that are still open:

worklogAuthor = currentUser() AND worklogDate >= -30d AND statusCategory != Done

Issues with worklogs containing a specific keyword (useful for billing codes):

worklogComment ~ "billable" AND worklogDate >= "2026-04-01"

All of these return issue lists, not time summaries. To get total hours from the results, you export to CSV and sum the Time Spent column yourself.

The gap: what JQL won't tell you

A few things you'd expect to be queryable that aren't:

You can't filter by amount of time logged. There's no worklogHours > 2 equivalent in JQL. You can find issues where a user logged work, but you can't filter to only issues where they logged more than a threshold.

You can't group by user. JQL returns a flat list of issues. If three people logged time on the same issue, you get that issue once — not three rows, one per author.

You can't query worklogs directly. JQL queries issues, not worklog entries. If a user logged two separate entries on the same issue on different days, you can't distinguish those entries via JQL — the issue just shows the total Time Spent field.

timespent is queryable but limited. You can write timespent > 2h to find issues where more than 2 hours have been logged total, but this is total across all users, not per-user.

timespent > 7200  // time is in seconds in JQL
project = MYPROJ AND timespent > 7200

Where the REST API does what JQL can't

If you need per-user time summaries, the Jira REST API is the right tool. Two endpoints are worth knowing:

Get worklogs for a specific issue:

GET /rest/api/3/issue/{issueIdOrKey}/worklog

Returns all worklog entries for that issue, including author, timeSpentSeconds, started date, and comment. This is the granular data JQL never surfaces.

Search issues and get their worklogs:
The practical pattern is two-step: use JQL via the search endpoint to get a list of issues, then fetch worklogs per issue.

// Step 1: get issues with worklogs in the date range
const searchResponse = await fetch(
  `${baseUrl}/rest/api/3/search?jql=worklogAuthor="${userEmail}" AND worklogDate>="${startDate}"&fields=summary,timespent`,
  { headers: { Authorization: `Basic ${btoa(`${email}:${apiToken}`)}` } }
);

const { issues } = await searchResponse.json();

// Step 2: get worklogs for each issue
const worklogs = await Promise.all(
  issues.map(issue =>
    fetch(`${baseUrl}/rest/api/3/issue/${issue.key}/worklog`, {
      headers: { Authorization: `Basic ${btoa(`${email}:${apiToken}`)}` }
    }).then(r => r.json())
  )
);

// Step 3: filter by author and date, sum time
const userWorklogs = worklogs
  .flatMap(w => w.worklogs)
  .filter(w => 
    w.author.emailAddress === userEmail &&
    w.started >= startDate
  );

const totalSeconds = userWorklogs.reduce((sum, w) => sum + w.timeSpentSeconds, 0);
const totalHours = (totalSeconds / 3600).toFixed(1);

This gives you what JQL can't: actual per-user time totals, filterable by date range, groupable however you need.

One gotcha: the /worklog endpoint paginates at 20 entries by default. For issues with a lot of logged time, you'll need to handle the startAt parameter:

async function getAllWorklogs(issueKey, baseUrl, auth) {
  let allWorklogs = [];
  let startAt = 0;
  const maxResults = 100;

  while (true) {
    const response = await fetch(
      `${baseUrl}/rest/api/3/issue/${issueKey}/worklog?startAt=${startAt}&maxResults=${maxResults}`,
      { headers: { Authorization: auth } }
    );
    const data = await response.json();
    allWorklogs = [...allWorklogs, ...data.worklogs];

    if (startAt + maxResults >= data.total) break;
    startAt += maxResults;
  }

  return allWorklogs;
}

The updated worklogs endpoint (often overlooked)

There's a less-known endpoint that's useful for syncing or auditing worklog data:

GET /rest/api/3/worklog/updated?since={timestamp}

Returns all worklog IDs updated since a given Unix timestamp in milliseconds. Useful if you're building a sync process and don't want to re-fetch everything — just poll for updates since your last sync.

const since = Date.now() - (7 * 24 * 60 * 60 * 1000); // last 7 days
const response = await fetch(
  `${baseUrl}/rest/api/3/worklog/updated?since=${since}`,
  { headers: { Authorization: auth } }
);

const { values, lastPage, nextPage } = await response.json();
// values = array of { worklogId, updatedTime }

Then fetch the actual worklog details in bulk:

POST /rest/api/3/worklog/list
body: { "ids": [worklogId1, worklogId2, ...] }

This is significantly more efficient than querying per-issue if you're maintaining any kind of time tracking integration.

When to use what

Goal	Use
Find issues where someone logged time	JQL with `worklogAuthor`
Filter open issues by who's working on them	JQL with `worklogAuthor` + status filter
Get total hours per user	REST API `/issue/{key}/worklog`
Build a timesheet view	REST API, aggregate by `author` + `started` date
Sync worklog data incrementally	REST API `/worklog/updated` + `/worklog/list`
Show time trends across sprints	Reporting add-on (JQL and API both get complex fast)

For the last row — if you need ongoing time reporting inside Jira without building and maintaining your own API integration, Report Hub handles the aggregation layer. It's a Forge app so the data stays inside Atlassian's infrastructure, which matters if you're in a regulated environment. The full breakdown of what's possible with Jira time tracking reports — including the JQL workarounds and their limits — is on the Grandia Solutions blog if you want more depth on the reporting side.

Why Developers Hate Jira and How to Make It Dev-Friendly Again

Alina Chyzh — Thu, 11 Dec 2025 14:21:03 +0000

Most development teams have a love–hate relationship with Jira. On paper, it's a powerful work-management platform designed to bring structure and transparency. In reality, many developers experience it as a friction engine: slow interfaces, complicated workflows, noisy dashboards, too many fields, and processes that grow heavier with every sprint.

Developers often joke that updating a task in Jira takes longer than fixing the bug inside it and for many teams, that’s uncomfortably close to the truth. The is how teams configure and use it.

This article explains the real reasons developers become frustrated with Jira, what damage poorly designed workflows cause, and how to make Jira lighter, faster, and more supportive of engineering work.

The Real Reasons Developers Hate Jira
It becomes a management tool, not a developer tool

Teams often turn Jira into a system for tracking, reporting, and controlling people rather than enabling engineering flow. Every status change becomes a process step. Every update becomes an audit entry and every sprint feels like a reporting exercise instead of collaboration. When Jira starts representing bureaucracy instead of value, developers disconnect from it.

Too many fields, too many statuses

A simple quick update often turns into a miniature epic: mandatory fields, dropdown lists with 40 options, tabs full of unused data. The more clicks a task requires, the less likely developers are to keep it updated. Over-engineered workflows slow teams down and create frustration long before any development work even starts.

Slow performance breaks deep-work cycles

Jira can be sluggish, especially in large organizations. If every transition takes 3–5 seconds, and those transitions happen dozens of times per day, developers lose focus. Momentum disappears. Instead of supporting flow, Jira interrupts it.

Reporting chaos undermines trust

Teams accumulate dashboards the way projects accumulate technical debt. Different charts show the same metric with slightly different filters; multiple dashboards contradict one another, leaders reference graphs developers have never seen. Instead of clarity, reporting generates confusion and eventually nobody trusts the numbers.

Time tracking becomes a punishment, not a tool

Time tracking isn't bad by itself. But when it becomes a micromanagement mechanism (log every minute,hours = productivity), morale drops fast. Developers stop updating tasks accurately because the system feels punitive, not helpful.

Too many boards and fragmented visibility

A team might have a main board, a triage board, a PM board, a QA board, a roadmap board, and three experimental boards from old initiatives. Tasks get duplicated or lost. Developers stop knowing where work truly lives.

Notifications: either overwhelming or nonexistent

Some developers receive 40+ notifications per day. Others receive none when something critical changes. Poor notification hygiene reinforces the perception that Jira adds noise rather than value.

What Poor Jira Experience Does to Teams

A noisy Jira environment does more than annoy peopl, it slows teams down.
Developers lose focus because they constantly switch mental contexts, cycle time increases because flow is interrupted, engineers avoid updating tasks because the system feels heavy, managers lose visibility because data becomes outdated or unreliable.

Over time, frustration with the tool becomes frustration with the process itself and that leads to disengagement, friction, and burnout. When developers stop believing in the process, velocity suffers regardless of how many metrics you track.

Jira Can Be Developer-Friendly
Simplify workflows aggressively

Most teams only need a small set of core statuses: To Do → In Progress → In Review → Done. Anything beyond that should be justified, not assumed. Simplicity restores speed and reduces errors.

Reduce fields to the essentials

If a field doesn’t influence planning, reporting, or workflow logic, remove it or make it optional. The fewer cognitive steps a task requires, the more consistently developers will keep it updated.

Automate the boring parts

Jira Automation can eliminate dozens of manual actions: moving tasks when a PR is created, assigning reviewers, closing resolved issues, surfacing stale items. When Jira does the repetitive work, developers stay focused on engineering, not administration.

Build developer-centric dashboards, not management dashboards

Useful metrics for developers include cycle time, review latency, throughput, and WIP. Unhelpful metrics include tasks completed per developer or one-dimensional time logs.

Teams often introduce tools like Report Hub when they need clean, consolidated, developer-friendly dashboards without maintaining multiple native Jira gadgets. Such tools reduce reporting clutter instead of adding to it.

One team, one board

If everything is important, nothing is. A single, authoritative board per team reduces duplication and confusion while keeping sprint work visible and manageable.

Integrate Jira into the developer workflow

A great Jira setup lets developers interact with tasks without leaving their environment.
VSCode plugins, Git integrations, Slack updates and keyboard shortcuts reduce friction dramatically. The best Jira experience is one that minimizes the need to open Jira at all.

What a Healthy Jira Setup Looks Like

Here’s a typical “before vs after” transformation:

Before

11 workflow statuses
20 required fields
multiple boards per team
dashboards full of conflicting metrics
long load times
developers avoiding task updates

After

4–5 clear statuses
only critical fields
one board per team
a small set of meaningful metrics
automation supporting transitions
developers updating tasks effortlessly

With the right balance of simplicity and automation Jira stops being a burden and becomes a natural part of the development lifecycle.

Jira Isn’t the Problem — Overengineering Is

Jira becomes painful when teams over-customize it, misunderstand metrics, or treat it as a surveillance tool rather than a collaboration platform. But when teams streamline workflows, reduce noise, automate tedious steps, and design dashboards around developer needs, Jira becomes fast, intuitive, and reliable.

Fix the system and Jira becomes one of the most powerful allies an engineering team can have.