Latest time in {ticket status} broken

The "Latest time in {status} ticket properties sound great, but I can’t seem to get them working. I’m seeing the “latest time in” and “cumulative time in” status values are randomly empty for lots of tickets. I can’t figure out any rhyme or reason to why these ticket properties are empty or not.

[I can’t upload a photo apparently, but it shows a half dozen tickets, all of which were created via email, half of which have "time to next response empty, and half of which have accurate values. Same for the “latest time in” entries, except that a ticket that has the SLA working will have the “latest time in” broken, and visa versa, and sometimes both will be working/broken.]

I was trying to manually configure SLAs via workflows because the SLAs (time to next response) are also broken, but it seems like everything’s just broken and randomly unpopulated.

It seems like manually switching the ticket status back and forth gets these values to start populating - right now we have workflows that move the tickets between statuses so that the SLAs pause when we’re waiting on a reply from the customer, but it seems if a ticket enters a stage via a workflow, the timers don’t start? I’m not sure if this is what it is, but manually changing statuses around seems to occasionally start the timer.

Is there a way to fix the SLAs and/or latest time in {stage} timers?

here’s the image now that i gained a “trust level”

Hi @SneedFeedAndSeed,

Latest time in [status ID]: the total time spent by the ticket in the status since it last entered the status. This is calculated based on the Date entered and Date exited properties.

The reason you’re not seeing a value here for tickets at first but after changing statuses is that it requires the exited date to be known.

In that sense, what you’re experiencing is expected behavior.

Best regards!

Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.

Hi @karstenkoehler,

Thanks for the reply, this helps. The other question though is why aren’t the SLAs being populated? Some tickets have it calculated, others have it as “–”, and other tickets don’t even have the placeholder “–”, it’s just empty. I can’t figure out any rhyme or reason to which tickets have this and which don’t. On our help desk SLA configuration, we’re using the “apply to all tickets” option and the only ticket statuses that pause SLA timers are “waiting on contact” and “spam.” Most of these tickets are neither of these, so why do they not have any SLA being calculated?

@SneedFeedAndSeed which properties exactly are you referring to?

  • Time to first response SLA due date: the date the ticket must have its first response by to meet the SLA. This property will only appear if you’ve set SLAs in the inbox.
  • Time to first response SLA ticket status: the ticket’s status based on the SLA for first response to a ticket. This property will only appear if you’ve set SLAs in the inbox. Options include:
    • Active SLA: an SLA is set for the ticket’s first response, but it’s not currently marked as Due soon, Overdue, or completed.
    • Due soon: the first response should be completed soon in order to meet the ticket’s SLA.
    • Overdue: the first response to the ticket is overdue based on the SLA.
    • SLA completed on time: the ticket’s first response occurred within the SLA time frame.
    • SLA completed late: the ticket’s first response occurred outside of the SLA time frame.
  • Time to first response in SLA hours: time between ticket created and first response within SLA hours. This property is only populated for help desk tickets and includes data starting from January 2025.
  • Time to close in SLA hours: time between ticket created and ticket closed within SLA hours. This property is only populated for help desk tickets and includes data starting from January 2025.
  • Time to close: the time between when the ticket was created and closed.
  • Time to close SLA due date: the date the ticket must be closed by to meet the SLA. This property will only appear if you’ve set SLAs in the inbox.
  • Time to close SLA ticket status: the ticket’s status based on the SLA for closing a ticket. This property will only appear if you’ve set SLAs in the inbox. Options include:
    • Active SLA: an SLA is set for the time to close the ticket, but it’s not currently marked as Due soon, Overdue, or completed.
    • Due soon: the ticket should be closed soon in order to meet the ticket’s SLA.
    • Overdue: the time to close the ticket is late based on the SLA.
    • SLA completed on time: the ticket was closed within the SLA time frame.
    • SLA completed late: the ticket was closed outside of the SLA time frame.

Hi @karstenkoehler,

Thanks for the links. Here’s what i’m seeing:

From my understanding, SLAs only apply for tickets created after the SLA is set up, so I sorted by create date and there’s still no rhyme or reason to which tickets have the “overdue” SLA (which means it’s being calculated) and which have empty fields.

As I mentioned, the only time SLAs are paused is when the status is “waiting on contact” or “spam”

Why won’t the SLAs calculate?

@SneedFeedAndSeed I don’t think I can troubleshoot this from afar without being able to poke around in the ticket records - the best route here would be to contact HubSpot support in-app.