Jira worklogs in a date range with worklogDate

A common question about Jira time: one activity has worklogs on 1 May (2h), 15 June (1h), 18 June (3h) and 2 July (1h), and the asker wants June’s hours only, 4h: “Quiero sumar solo las horas trabajadas en Junio” (Community, August 2026). JQL’s worklogDate is where most people start. This page says what it finds across your spaces, where it stops, how to get only the period’s hours without an app, then what Logline does.

What worklogDate finds

worklogDate >= 2026-06-01 AND worklogDate <= 2026-06-30

finds every issue you can browse, in every space, with at least one worklog in June. Add project in (ACME, NWND) to keep to some spaces, or worklogAuthor in membersOf("web-team") to keep to a team. Jira’s date functions work too: worklogDate >= startOfMonth(-1) AND worklogDate < startOfMonth() means last month on whatever day it runs, so a saved filter moves with the calendar (JQL fields).

It returns issues. The activity above is found, and its Time spent says 7h: all four worklogs.

Where it stops

• Each clause can match a different worklog. The fields search for issues, so worklogAuthor = currentUser() AND worklogDate >= startOfWeek() also finds an issue you logged on last year if a colleague logged on it this week.
• The most recent 1,000 worklogs. Atlassian’s JQL documentation says that if an issue has more than 1,000 worklogs, JQL searches only the most recent ones.
• The hours beside each issue are all-time. Time spent, on screen and in the export, is the issue’s total from every date and every author. The all-fields export carries every worklog in its Log Work columns, and Export Jira worklogs to Excel shows how to split them into rows.
• The day depends on a time zone. Jira reads the dates in a search in your own time zone, so a worklog logged late in the evening in New York can fall in the next month for a colleague in Riga. Two people can get different lists at a month’s edges.

Only the period’s hours, without an app

Both routes need someone who can run a script with an API token:

• Issue by issue: for each issue the search found, GET /rest/api/3/issue/{issueIdOrKey}/worklog with startedAfter and startedBefore, in Unix milliseconds, returns only the worklogs started in that window. For the activity above that is the two June worklogs, 1h and 3h.
• Across the whole site: GET /rest/api/3/worklog/updated?since= lists the IDs of the worklogs updated since a moment, 1,000 to a page, and POST /rest/api/3/worklog/list returns up to 1,000 worklogs by ID. Start from a moment before the period, then keep the worklogs whose started falls inside it.

Both return only the worklogs the caller may see (Atlassian).

With Logline

Logline is our app. It reads the worklogs and keeps the ones inside the period:

1. Open Apps › Logline and pick a period: a chip such as Last month, a rolling period under More periods, or a Custom range of up to 400 days.
2. Under Edit report, the scope is every space you can see, chosen spaces, a saved filter or JQL. The scope picks the issues; the period decides which of their worklogs count.
3. Each worklog is checked against the period and the people one by one, so the author and the date belong to the same worklog. The activity above shows 4h in June.

How it counts:

• A worklog counts on the day it started, in the viewer’s time zone or in each author’s, and every report names the time zone under its total (Periods, days and time zones).
• A report reads up to 10,000 issues and 50,000 worklogs; above that it says so and asks for a shorter period or a smaller scope, rather than showing a partial total.
• Logline finds the issues with the same worklogDate search, so Jira’s 1,000-worklog limit applies to it too, on an issue with that many.

More on the Logline home page.