Skip to main content
SLA policies define the service level commitments you make to your clients. Each policy sets response time and resolution time targets based on ticket priority, scoped to your business hours and timezone.

​
What SLAs track

Every SLA policy measures two things:
  • Response time — How long until a technician sends the first reply after a ticket is created.
  • Resolution time — How long until the ticket reaches Resolved status.
Both timers respect business hours. Time outside your configured working hours does not count against the SLA.

​
Creating an SLA policy

Each SLA policy covers one priority level. To cover all four priorities (Critical, High, Medium, Low), create one policy per priority — for example, a “Critical Response SLA” policy with a 15-minute response target and a 4-hour resolution target, then a separate policy for High, and so on.
1

Navigate to SLA Policies

In the PSA module sidebar, click SLA Policies, then click New Policy.
2

Name the policy and pick its priority

Give it a name (e.g. “Critical Response SLA”) and choose the single ticket priority it applies to.
3

Set response and resolution targets

Enter the response time and resolution time, both in minutes.
4

Choose scope and At-Risk threshold

Under Applies To, leave it as “All customers (generic fallback)” or pick one client to scope this policy to just that client’s tickets at the matching priority — a per-customer policy wins over the generic default. Set the At-Risk Threshold percentage (default 80%) that determines when a ticket flips to the At Risk status. A generic (non-customer-scoped) policy can also be marked Default Policy to auto-apply to new tickets at that priority.
5

Configure business hours

Toggle 24x7x365 for a round-the-clock SLA, or set start/end times, business days, and a timezone. SLA timers only run during these hours unless 24x7x365 is on.
6

Save

Click Create Policy.

​
SLA statuses

A breached SLA cannot be reversed. Even if the ticket is later resolved, the breach is recorded permanently for reporting purposes.

​
SLA pausing

The SLA resolution timer pauses in two situations:
  • Waiting on Customer — the technician has replied and is waiting on the client. The timer resumes when the customer responds or the technician moves the ticket back to In Progress.
  • Waiting Approval — the ticket is on hold for an approval decision. The timer resumes when the approver responds, or when a technician manually moves the ticket to a different status. The approval link expires after 7 days; an expired, undecided request does not automatically resume the timer — a technician needs to change the ticket’s status manually, or send a new approval request.
Both pauses only skip time outside your resolution target that isn’t the technician’s to control — time spent waiting on someone outside your team never counts against you. Response time is not paused — it is measured only once (time from creation to first reply).

​
Escalation notifications

An hourly job checks every open ticket’s SLA status. When a ticket first becomes At Risk or Breached, Regentra automatically notifies the assigned technician by email and in-app notification; if the ticket is unassigned, or the status is Breached, every admin/MSP admin on the org is notified too. This escalation notification is automatic and isn’t configured per policy — the At-Risk Threshold on each SLA policy is what controls how early the At Risk notification fires.

​
SLA compliance reporting

View SLA performance across clients and time periods in PSA → PSA Reports. The Service Desk Overview report includes:
  • SLA compliance percentage (met vs breached)
  • Average response and resolution times
  • Breach trends over time
  • Per-client SLA performance breakdown
SLA data is also visible on individual tickets via the SLA badge, and on the PSA dashboard as an aggregate metric.