Total / Adjusted Time Open

This article will explain the difference between the "Total Time Open" and "Adjusted Time Open", along with use cases for each.

Total Time Open

The "Wall Clock" Time: This is exactly how long an issue has been open in real-time, from the moment it was submitted until the present (or until it was closed).

Business Hours Awareness: Even if you have "Hours of Operation" configured (e.g., 9:00 AM – 5:00 PM), the Total Time Open calculation starts accruing once the system "clocks in" during your operation hours. For example, if an issue is submitted on Saturday but your hours begin Monday at 9:00 AM, the clock for Total Time Open doesn't actually start until Monday morning.

Use Case: Use this to see the literal duration that an issue was open within your active business hours.


Adjusted Time Open

The "Work" Time: This is the Total Time Open minus any "paused" time.

How it Pauses: Issuetrak uses Substatus Rules to pause the clock. For example, you can set a rule so that if an issue is moved to a substatus like "Waiting on Customer" or "On Hold," the clock stops ticking.

The Formula: Adjusted Time Open = Total Time Open - Time Spent in "Pause Clock" Substatuses.

Use Case: This is the most important metric for SLA (Service Level Agreement) compliance and Workflow escalations. It shows the actual time your team was responsible for the issue, excluding the time they were waiting on external factors.


What is TotTimeOpenMins?

This field represents the value stored in the database. However, it is not recommended to use this value directly from the database for reporting purposes, as we will explain.

TotTimeOpenMins is a fraction of the total number of minutes in a single day (1440). If the value for TotTimeOpenMins is 1, then that would mean 1440 minutes, which is 1 day.

If the value is "0.933333333333333" then it can be multiplied by 1440 to get the total number of minutes (rounded, that would be 1344) that the issue has been open for. 1344 divided by 60 minutes yields 22.4 hours.


Formulas

x = Value in table
1440(x) = Time in minutes
1440(x) / 60 = Time in hours

When viewing an issue inside Issuetrak, the value for Total Time Open is displayed as HH:MM. This particular calculation (22.4) is therefore displayed as 22:24. The .4 part of 22.4 does not represent 40 minutes; it's 4 tenths of an hour (60 min * .4), which is 24 minutes.

One very important thing to keep in mind is that the IssuesTimeOpen table is updated constantly by Issuetrak. When someone accesses an issue, we calculate the TotTimeOpen for that issue and update the table accordingly. If a report involving the field TotTimeOpenMins is run using Report Writer, then the TotTimeOpen for all the issues is calculated and will appear on the report, and the table will be updated accordingly.


Why is it a bad idea to use this value for reporting?

If no one has accessed the issue or ran a report involving that issue, and you try to grab the field from the database, it will be out-of-date. Therefore, the IssuesTimeOpen table should not be relied upon for SQL queries outside of Issuetrak to determine how long an issue has been open.  IssuesTimeOpen is mainly a special table specifically designed for Issuetrak.

If it's imperative that this information be gathered outside of Issuetrak, then it will be necessary to review the stored procedure sp_IssuesTimeOpen_Upd for more information. This requires an advanced understanding of SQL and the Issuetrak database schema.


FAQs

How do I choose which substatuses "pause" the Adjusted Time Open clock?

This is controlled via Substatus Rules. Administrators can designate specific substatuses (like "Waiting on Customer" or "Third Party Review") to pause the clock. Once an issue is moved into one of these substatuses, the system stops adding minutes to the Adjusted Time Open until the substatus is changed back to an "unpaused" state.

Why do my SQL reports show different time-open values than the Issuetrak interface?

The IssuesTimeOpen table in the database is only updated when a user views the issue or when a Custom Report is run. If you are querying the database directly via SQL and no one has interacted with the issue recently, the value in the table will be out of date. To ensure 100% accuracy, it is always recommended to use the Issuetrak Custom Reports.