Jira Test Execution Time: Elapsed vs Logged Work in Xray Cloud

A tester finishes a run in Xray Cloud, but the Test Execution's Jira Time Spent value does not match the timer. That difference does not necessarily mean execution data is missing. Xray records elapsed time with its run timer, while Jira worklogs record time that someone deliberately submits. A completed result does not automatically turn the timer reading into logged work.

For a QA lead, the useful question is what each value represents. Elapsed time helps describe the duration recorded for a particular run. Logged time records reported effort on the Test Execution issue. They can be equal, but equality is a choice about what to log, not a consistency rule that every execution must satisfy.

Compare the Run Timer With the Execution Worklog

Start with the record being measured. A reusable Xray Test describes what to check. A Test Run is an instance of that Test within a Test Execution, with its execution context and result. The Test Execution is the Jira issue on which execution work can be logged. Changing that issue's Jira workflow status is a different operation from changing an individual Test Run's execution status.

Keeping those objects separate prevents an issue total from being mistaken for a single run's duration. For more background on responsibilities and results, see the explanation of Jira test execution assignments, statuses, and blockers.

Criterion	Xray Cloud Elapsed Timer	Jira Logged Work on Test Execution
Record scope	Individual Test Run	Jira Test Execution issue
How it is recorded	Timer records elapsed intervals	A person submits a work log
Pause and completion	Manual pause; final result pauses timer	No new work log is implied by a result
Restart at TO DO	Timer resets	Review existing work logs separately
Appropriate question	How much time did the run timer record?	How much effort did people report?
Main caution	Pauses, resets, and edits affect interpretation	Avoid logging the same effort through both entry routes

The timer cannot establish how much labor every participant contributed. If testers work in parallel, the release's elapsed window and their combined effort answer different questions. A tester may also spend effort investigating a failure after stopping the run timer. Conversely, leaving a timer running during an interruption can make its reading unsuitable as an effort entry without review.

Treat any decision to copy elapsed time into a worklog as a review step. Xray explicitly allows logging the displayed elapsed value, another value, or nothing. A team using time tracking for staffing or billing therefore needs an inclusion policy, such as whether execution effort includes evidence preparation and failure investigation. That policy is a team convention, not a timer setting that can infer what people were doing.

How the Xray Cloud Timer Starts, Pauses, and Resets

Xray's Cloud execution guide describes a timer on the Test Run execution screen. Its visibility depends on the relevant project setting. Editing the timer's value also depends on the setting named Set the value of the Time Tracker. A missing or noneditable timer should prompt a configuration and permission check, not an assumption that the Jira worklog is broken.

Running Intervals and Final Results

The documented automatic behavior follows the Test Run's execution status: changing it to EXECUTING starts the timer, while changing it to a final status, such as PASSED or FAILED, pauses it. Xray also documents manual controls to start, pause, and reset the timer. Use the available controls in the installed interface rather than assuming an older screenshot matches every current screen.

Pause handling affects the meaning of the duration. If the team excludes waiting for an unavailable environment from active execution time, the tester needs to apply that convention consistently. Recording a final result pauses the timer, but does not prove that all related labor has ended. Defect clarification or evidence organization may still need to be recorded according to the team's effort policy.

Check custom statuses before extending this behavior to a local workflow. Xray supports custom Test Run statuses, but a label such as Blocked should not be assumed to have the same timer behavior as a documented final result. Confirm its configured meaning with the project owner. The Jira issue's workflow and the app's run-result model should remain distinguishable in both instructions and reports.

Returning a Run to TO DO

The Cloud guide says the timer resets when the Test Run changes to TO DO. A reset can therefore change what the current timer reading represents. Before using that transition to begin again, preserve the prior attempt's context and any duration information needed for the team's records. Do not expect the displayed timer to serve as a cumulative history of all attempts after resets.

Review Jira worklogs independently. Resetting a timer is not a worklog-correction procedure, and the timer reading alone cannot tell you which entries someone already submitted. Inspect the Test Execution's worklog before entering effort for a retry. If an entry needs correction, use Jira's worklog controls with the required permissions rather than submitting a compensating duplicate.

Also distinguish a timer reset from the execution-definition Reset operation. Xray documents a separate reset when updating a changed Test definition, which can erase previously saved execution information such as status, evidence, and defects. Do not use that operation merely to make a duration look tidy. Preserve execution evidence and choose an appropriate history-preserving approach for a new attempt.

Older records need care too. Xray's Time Tracking reference says legacy Test Runs predating the timer used Started on and Finished on dates for elapsed time. Subtracting those timestamps is therefore not a safe universal replacement for the current timer reading. Establish which model a historical report uses before comparing it with newer runs.

Log Execution Effort on the Test Execution

Xray offers a logging shortcut from the run execution screen, and Jira provides its normal work-logging route on the Test Execution issue. Time added through the Xray logging dialog is reflected in that Test Execution's worklog. These are alternative entry routes for reporting work, not separate quantities that should both be entered for the same effort.

Check access before documenting a team's procedure:

• Xray execution requires the documented Browse and Resolve permissions on the Test Execution, with no configured workflow restriction preventing execution of the Test or Test Execution.
• Jira work logging requires the appropriate Browse spaces and Work on work items permissions in Atlassian's current terminology. Older interfaces may still use project and issue wording.
• Time tracking must be available in the relevant Jira configuration. Enabling or disabling it is an administrative task, separate from a tester's permission to enter work.
• Editing or deleting an existing entry requires the applicable own-worklog or all-worklog permission. Permission to add work does not establish permission to correct anyone's entries.

A person who can open an execution page read-only may still be unable to execute the run. Likewise, permission to execute a test does not establish permission to submit or edit Jira worklogs. Resolve the specific missing capability with the administrator rather than granting broader rights as a troubleshooting shortcut.

For the native Jira route, Atlassian documents this sequence. Apply it to the intended Test Execution, checking the issue identity before saving:

1. Review the existing worklog and determine whether this effort has already been recorded through the run-screen shortcut or another reporting process.
2. Open the Test Execution and select More actions, then Log work, or select its Time tracking field.
3. Complete the Log time fields with the effort you intend to report. Use explicit units, such as hours or minutes, because an unqualified number uses the administrator's default time unit.
4. Select Save, then inspect the Test Execution's worklog to confirm the intended entry and reporting scope.

The opening and final checks are recommended safeguards around the documented logging action. They do not describe automatic duplicate detection. If a team has installed another time-tracking app or custom integration, establish what it writes before using both it and manual entry. Xray's documented timer behavior does not establish that every integration synchronizes or deduplicates worklogs.

Keep execution effort off the reusable Test specification when it belongs to a particular execution. Specification maintenance can have its own effort record, but copying the same execution work there makes later totals misleading. Xray also warns against logging the same execution effort on both a Test Plan and its Test Executions. Planning and environment setup can be accounted for separately, with clearly defined boundaries.

When correcting a worklog, review the remaining estimate as well as the entry itself. Atlassian documents separate edit and delete permissions and cautions that remaining-time calculations may need attention after changes. A corrected worklog entry should not be treated as proof that every estimate or report now expresses the intended scope.

Handle an Interrupted Checkout Run Without Duplicating Effort

Consider a fictional checkout regression scenario. No Jira records, timers, or application tests are being operated here. Maya is responsible for a payment run within a release Test Execution. The team has agreed to report hands-on execution and evidence preparation as execution effort, while recording unrelated planning separately.

Maya changes the run to EXECUTING and begins the checkout checks. A payment sandbox becomes unavailable before she can complete the case. Under the team's convention, she pauses the timer while waiting, and records why the attempt is interrupted. The pause affects recorded duration; the note explains the interruption. Neither action creates a Jira worklog entry by itself.

When access returns, Maya continues the run. She observes a payment failure, retains the expected and actual behavior, and records FAILED. The documented final-result behavior pauses the timer. Before logging work, she considers the effort she intends to report, including the agreed evidence preparation, and checks whether an entry already exists on the Test Execution. She uses a chosen logging route for that effort, rather than repeating it later through the other route.

Meanwhile, Leo can be working on a separate tax-calculation run in the same Test Execution. His reported effort belongs to his contribution. The issue's logged total should not be interpreted as Maya's timer reading or as the calendar length of the release's testing window. Parallel work, different run scopes, and the team's effort-inclusion policy explain why those measures can diverge.

If the payment fix requires another attempt, preserve the failed build, result, and relevant evidence before choosing how to rerun. Do not reset to TO DO solely to reconcile a worklog mismatch. A fresh timer reading does not explain prior labor entries, and a clean-looking current result should not erase the context needed to understand the earlier failure.

Reconcile Reports Before Comparing Teams

When a timer and a report disagree, identify the source of each value before changing either. Xray's Time Tracking reference recommends the Time Spent field for logged time on a Test Execution. Its timer-based elapsed measure has a different scope. A report that groups execution issues may also encompass work associated with multiple runs, so inspect its grouping and filters before comparing it with an individual execution screen.

A useful reconciliation records:

• The object being measured: reusable Test, individual Test Run, or Test Execution issue.
• The value's source: timer recording, Jira worklog, or estimate.
• The attempt, build, environment, and reporting period included.
• The units and the policy for waiting, investigation, planning, and shared work.
• The existing entries and any reset or correction relevant to the comparison.

Compare estimates with actuals only when their scope matches. An estimate for running selected tests is not directly comparable with a total that also includes planning or environment setup. Similarly, a short timer duration does not establish efficient testing, and a larger worklog does not establish waste. Those values need the tested scope, interruptions, people involved, and evidence of what was completed.

Choose the measure according to the decision: use timer-recorded duration to discuss a run's timing, and Jira worklogs to discuss reported execution effort. Agree who logs that effort, where it belongs, and what it includes. Then review the Test Execution's existing entries before adding more, so different entry routes and later attempts do not count the same work again.