Jira and Tempo make it easy to collect time across a large number of issues. That is useful for capacity planning, billing, forecasting, and project reporting—but it can also create a problem: some issues should not be included in every report.
Administrative tasks, internal meetings, training, travel, leave, and management activities may all be valid issues for time tracking. However, including them in a client-facing or delivery-focused report can distort the results.
The best solution is usually not to remove issues manually inside Tempo. Instead, define the reporting scope in Jira with a saved JQL filter, then use that filter in Tempo.
The recommended approach: filter in Jira first
Tempo can use Jira filters based on JQL to control which issues appear in a report. This gives you a single, reusable definition of the report scope rather than a manual exclusion list that has to be rebuilt each time.
A typical workflow looks like this:
- Open Jira issue search.
- Switch to advanced JQL mode.
- Write a query that includes the work you want and excludes the work you do not want.
- Save the query as a Jira filter.
- Share the filter with the relevant users or project roles.
- Select that saved filter when configuring the Tempo report.
Filtering before the report loads also keeps the dataset smaller, which can help report performance on larger Jira instances. Tempo documents saved Jira filters and advanced filtering as supported ways to narrow report data.
Excluding a small number of known issues
If you only need to exclude a few specific issues, use the issue key with NOT IN:
project = ABC
AND key NOT IN (ABC-123, ABC-456, ABC-789)
Replace ABC with your project key and replace the example issue keys with the issues you want to remove.
This approach is quick and clear. It works well when the exclusions are stable and limited—for example, when a project has one recurring travel issue or one internal administration issue.
Combining an existing filter with exclusions
If you already have a saved Jira filter that defines the general scope, you can build on it:
filter = "All project work"
AND key NOT IN (ABC-123, ABC-456)
This avoids duplicating a long query and makes the exclusion rule easy to see.
A more maintainable approach: exclude by label
A list of issue keys can become difficult to maintain. New administrative issues may be created, old issues may be replaced, and someone may forget to update the filter.
For recurring reporting rules, use a dedicated label such as:
exclude-from-delivery-report
Then use this JQL:
project = ABC
AND (labels IS EMPTY OR labels NOT IN ("exclude-from-delivery-report"))
The labels IS EMPTY condition is important because it ensures that issues without labels are still included.
This pattern works particularly well when several people create issues and the reporting rule needs to be visible directly on the issue. A user can apply the label, and the saved filter automatically keeps the issue out of the relevant Tempo report.
Excluding whole categories of work
If the unwanted work is consistently represented by a Jira field, use that field instead of maintaining issue keys or labels.
Exclude issue types
project = ABC
AND issuetype NOT IN ("Administrative", "Travel", "Training")
Exclude components
project = ABC
AND component NOT IN ("Internal", "Management")
Exclude a specific status category
For example, if a report should focus only on active delivery work:
project = ABC
AND statusCategory != Done
Choose the field that best reflects the business rule. Issue type is usually a good choice when the category is structurally different. A label is more flexible when the same issue type can sometimes be included and sometimes excluded.
Be careful with sub-tasks
One common source of confusing results is sub-task worklogs.
Suppose ABC-123 is an administrative parent issue, and someone logs time on ABC-123-1, a sub-task beneath it. Excluding only the parent key may not produce the result you expect if the Tempo report is configured to include sub-tasks.
Before relying on the filter, check:
- Whether the report includes sub-task worklogs.
- Whether the excluded work is logged on the parent issue, sub-tasks, or both.
- Whether your JQL needs to account for the parent-child structure.
- Whether Tempo's report configuration aggregates sub-task time into parent issues.
Tempo provides a separate option for including sub-tasks when filtering by issues, so this setting should be tested explicitly.
Excluding issues is not the same as excluding worklogs
There is an important difference between these two goals:
Exclude an entire issue
Use issue-based JQL when no time from the issue should appear in the report:
project = ABC
AND key NOT IN (ABC-123, ABC-456)
Exclude only certain types of time
If an issue contains both reportable and non-reportable work, excluding the entire issue may be too broad. In that case, consider whether the distinction should be represented by a Tempo work attribute, account, billing category, or another dedicated field in your configuration.
For example, if a single delivery issue contains both billable and non-billable time, an issue-level JQL filter cannot distinguish between those worklogs. You need a worklog-level reporting dimension instead.
Test the filter before using it in a formal report
A saved filter can look correct while still producing unexpected results. Test it in Jira first:
- Run the JQL in issue search.
- Confirm that the issues you expect to see are present.
- Confirm that the excluded issues are absent.
- Inspect any related sub-tasks.
- Compare the resulting issue list with a Tempo report for the same period.
- Check totals before and after applying the filter.
This is especially important when the report is used for invoicing, utilization, management reporting, or compliance.
Which method should you choose?
Situation | Best method |
|---|
A few fixed issues must be excluded | key NOT IN (...)
|
New issues may need to be excluded over time | A dedicated label |
Entire categories should always be excluded | Issue type or component |
The same scope is used across multiple reports | A shared saved Jira filter |
Only some worklogs on an issue should be excluded | Tempo work attributes, accounts, or billing fields |
A practical pattern for most teams
For many teams, the most durable setup is:
project = ABC
AND (labels IS EMPTY OR labels NOT IN ("exclude-from-delivery-report"))
Save this as something like Delivery reporting – exclude internal work, document what the label means, and use the filter in the relevant Tempo reports.
This creates a simple governance model:
- Jira stores the reporting classification.
- The saved filter defines the scope.
- Tempo uses the filter to produce the report.
- The team can review the excluded issues directly in Jira.
Final recommendation
Use a saved Jira JQL filter as the source of truth for Tempo report scope. For a one-time cleanup, exclude issue keys directly. For a recurring reporting rule, use a label, issue type, component, or another consistent field. Always test the filter with sub-tasks and confirm whether you are excluding entire issues or only specific categories of worklogs.
The result is more consistent reporting, less manual cleanup, and a clearer explanation of why certain Jira work appears—or does not appear—in a Tempo report.
