Require time to be logged in Jira before moving issues forward

If you’ve ever opened a Done issue in Jira and seen “Time spent: 0m”, you know the pain. Reports become useless, teams forget to log work, and suddenly nobody trusts the numbers.

A lot of people search for things like:

• “Jira require time to be logged before transition”

• “block Jira transition until worklog exists”

• “Jira workflow validator logged time”

Out of the box, Jira Cloud doesn’t ship with a validator that does exactly this.That’s why we added a “Require time to be logged” workflow validator to our app Time Tracking Fields for Jira.

This post shows what the validator does, how it works under the hood, and how to configure it step by step.

The problem: issues closed with zero logged time

Most teams have some version of this rule written in their process docs:

“Don’t move an issue to Done if you haven’t logged your time.”

In reality:

• work is busy,

• transitions happen quickly,

• logging time is the first thing people forget.

The result:

• issues in Done with no worklogs,

• sprint and project reports that under-report real effort,

• confusion in retrospective meetings (“We know we worked on this… where is the time?”).

What you really want is Jira itself to enforce this rule, not just process guidelines.

The solution: “Require time to be logged” workflow validator

The Require time to be logged validator lets you:

• block a Jira transition (for example In Progress → Done)

• until a minimum amount of work time is logged on the issue.

Key properties:

• It uses Jira’s native Time Tracking, the same Time spent field your team already sees on issues.

• It works in company-managed and team-managed projects.

• It’s configured per transition, so you can have different thresholds in different places.

How the validator works (in plain terms)

When you add the validator to a transition, here’s what happens:

1. A user tries to move an issue using that transition (for example In Progress → Done).

2. The validator checks how much time has been logged on the issue via Jira’s standard Log work / Time Tracking.

3. It compares that amount with the minimum duration you configured, such as 30m, 2h or 1d 2h.

4. If logged time is below the minimum, the transition is blocked and the user sees a clear error message.

5. If logged time is equal to or above the minimum, the transition goes through as normal.

   
   

How to configure “Require time to be logged” in Jira

You add the validator directly in the Jira workflow editor, just like any other validator.

1. Open the workflow and select a transition

• Go to Project settings → Workflows.

• Edit the workflow that contains the transition you care about (for example the one that ends in Done).

• Click on the transition you want to protect, such as In Progress → Done or Ready for QA → Done.

2. Add the validator

• In the transition panel, open the Validators tab.

• Click Add validator.

• Choose Require time to be logged from the list and continue.

3. Set the minimum required time

Now you configure how much work needs to be logged before the transition is allowed.

You enter the value using Jira’s usual duration format, for example:

• 30m

• 2h

• 1h 30m

• 2w 3d 4h

This becomes the threshold the validator checks for that transition.

4. Publish the workflow

• Save your changes.

• Publish the workflow so the validator becomes active for that project.

From this moment on, every time someone uses that transition, Jira will enforce the “minimum logged time” rule automatically.

What users see when the rule blocks a transition

When the threshold is not met and someone tries the transition, they get a clear, actionable message.

Example: you configured 1 hour as the minimum:

The transition is blocked; the status stays unchanged.The user can:

1. Log time using Log work / Time Tracking on the issue, then

2. Retry the transition, which now succeeds once the minimum is met.

Example: enforcing “no time, no Done” for development issues

Let’s take a simple but common scenario.

Goal: make sure developers always log their work before closing a task.

1. Open the workflow for your development project.

2. Select the transition In Progress → Done.

3. Add the Require time to be logged validator.

4. Set the minimum logged time to 30m.

5. Publish the workflow.

Now:

• Developers can move issues between earlier statuses (To Do, In Progress, In Review) without restriction.

• When they try to move an issue to Done:

  • if less than 30 minutes is logged, they see the error and must log work first;

  • once at least 30 minutes is logged, the transition goes through normally.

Over time, this gives you:

• far fewer “Done with 0m logged” issues,

• more accurate sprint and project reports,

• better confidence in any metrics built on Time spent.

Other ways teams use the “Require time to be logged” validator

Because it’s a standard workflow validator, you can reuse it widely:

• QA exit criteriaRequire at least 15m or 30m of logged time before moving from In QA to Done, so you know that testing actually happened.

• Support SLA trackingOn support transitions like Waiting for Customer → Resolved, require a minimum of 5m or 10m to ensure agents don’t “touch and close” issues without logging time that should be billable.

• Review or approval stepsRequire at least 1h logged before moving to Ready for Release, so you know review, documentation or release preparation actually took place.

Each transition can have its own threshold, so you can be more relaxed in early stages and more strict when moving to final statuses such as Done or Resolved.

Why a validator is better than “please remember to log time”

You can try to solve this problem with process docs and reminders:

• “Always log time before closing the issue.”

• “Sprint is over, remember to update your worklogs.”

But that approach:

• relies on people remembering,

• breaks down when deadlines are tight,

• still lets issues slip through with zero logged time.

A workflow validator has different properties:

• It’s automatic – it runs on every transition.

• It’s consistent – it applies the same rule to everyone.

• It’s self-explanatory – the error message tells users what to do.

You stop chasing people manually, and Jira itself becomes the enforcement layer.

How this fits into Time Tracking Fields for Jira

The Require time to be logged validator is part of a bigger idea behind Time Tracking Fields for Jira:

• extend Jira’s time tracking,

• keep everything native (no external databases, no custom scripts),

• give teams more control over how time is tracked and enforced.

Today the app lets you:

• add multiple Jira-style time tracking fields per issue (Dev Time, QA Time, SLA Time, Contract Hours, and more),

• report on them with JQL, dashboards, automation and exports,

• and now enforce logging via the Require time to be logged validator on your workflows.

If you want Jira to enforce “no time, no Done” instead of chasing people for worklogs, try this validator in your own instance. Install Time Tracking Fields for Jira from the Atlassian Marketplace and start using the Require time to be logged rule on your key transitions.