You'll see two SLA clocks on every ticket: response and resolution. They measure different things and they don't pause when you go to lunch.
Response time
This is the window from when you submit the ticket to when a technician first engages — reads the ticket, asks a clarifying question, or starts work. It is not the time to resolution. Hitting this target just means we acknowledged you within the agreed window.
A technician posting "Looking at this now, will update in 30 min" counts as a response. So does asking you a question. Auto-generated confirmation emails do not.
Resolution time
This is the window from submission to Resolved status. "Resolved" means the technician believes the issue is fixed; you have a chance to confirm before it auto-closes.
The clock pauses when status is Waiting for Customer — i.e. we asked you a question and you haven't answered. That's intentional: a tech can't fix a problem they can't reproduce without your input.
When the clock breaches
If a deadline passes, the ticket is flagged as SLA breached and a notification goes to the on-duty manager. They'll either escalate the ticket, reassign it, or contact you with an explanation. A breach is not "you didn't get help in time" — it's a process trigger that surfaces tickets that need management attention.
How priority affects the clock
The matrix in [Understanding ticket priorities](/kb/understanding-ticket-priorities) sets the deadlines. P1 has 15 minutes for first response; P4 gets a business day. The same priority delivers the same SLA regardless of who you are.
Contract clients
If your organization has a service contract, your negotiated SLAs apply instead of the published defaults — usually tighter. Sign in to your client portal to see them.
When to ask about SLA status
Ask in a ticket comment. The tech can show you the current deadline and the time elapsed. We don't hide them.