> For the complete documentation index, see [llms.txt](https://docs.usepylon.com/pylon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usepylon.com/pylon-docs/support-workflows/slas-and-timers.md).

# SLAs and Timers

Set differentiated service level agreement timers on customer issues.

SLAs (Service Level Agreements) define how quickly you want to respond to, follow up on, and resolve customer issues.

Pylon supports four types of issue SLAs:

1. First Response Time: How long the customer waits for the first qualifying customer-visible reply. For tickets, timing normally begins when the ticket is created. For conversations, it begins with the first qualifying customer message. Replies from Pylon AI Agents count as a first response. Internal notes, private messages, and trigger-generated automatic messages do not count.
2. Next Response Time: How long the customer waits for a subsequent reply after the first response. Timing begins when the customer sends another qualifying message and ends when a team member sends a qualifying customer-visible reply.
3. Follow-up Time: How long it takes your team to send another customer-visible update when your team was the last to respond. Unlike Next Response Time, Follow-up Time is proactive and it measures whether your team follows up without waiting for another customer message. Internal notes do not count.
4. Resolution Time: How long it takes to resolve an issue. Closing the issue finalizes resolution time. Pylon measures it through the latest qualifying customer-visible reply from your team. If there is no qualifying reply, it uses the time the issue was closed. For a team SLA, Pylon uses that team’s latest qualifying reply or falls back to the close time.

Changes to SLA rules and support-hour settings apply going forward. Completed historical metrics are not recalculated.

Pylon also tracks **active time** — how long teammates actually spend working an issue. It has no target and cannot breach, so it is not an SLA, but it appears alongside the SLA timers on the issue and shares their [counting settings](#counting-settings).

## Setup <a href="#setup" id="setup"></a>

1. Visit the [SLAs page](https://app.usepylon.com/settings/slas) (**Settings > Workflows > SLAs**) and click **Add Issue SLA**
2. Select from one of the available templates for common SLA configurations for a good starting point

<figure><img src="https://982123570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9hXBoCTTNw5flARlUVJf%2Fuploads%2FSwDlear76JtoX64aVVc3%2FCleanShot%202025-06-03%20at%2021.34.25%402x.png?alt=media&amp;token=7148a437-c1af-4270-ab30-0b02c54021b4" alt=""><figcaption></figcaption></figure>

3. Modify the trigger with the conditions and values that make sense for your business. SLAs can be applied based on many factors, including the priority of the issue, the type of customer who raised it, etc.

### Notification <a href="#sla-alerts" id="sla-alerts"></a>

To setup notifications for SLAs, choose the "Send Slack notification on SLA breaches" template. Update the channel to your preferred one, or the action to a different notification type (such as email).

When an issue violates an SLA

1. The configured action will be taken, for example notifying a Slack channel
2. Users can also subscribe to notifications for SLA breaches on issues they are assigned to on the [notifications page](https://app.usepylon.com/settings/notifications).

### Support Hours <a href="#support-hours" id="support-hours"></a>

If you want SLAs to only increment during your working hours, you can configure Support Hours on the [Settings Page](https://app.usepylon.com/settings/support-hours). This makes sure that weekends and evenings will not inflate your count of SLA breaches.

### Counting Settings

Counting settings control when SLA and metric timers run. Find them under **Settings > Workflows > SLAs > Counting settings**. Changes apply to new issues only.

For each metric, choose the statuses in which **Time counts when**:

| Metric              | Timer runs while                                                       |
| ------------------- | ---------------------------------------------------------------------- |
| First response time | The issue is in a selected status                                      |
| Next response time  | The customer was last to respond and the issue is in a selected status |
| Follow-up time      | Your team was last to respond and the issue is in a selected status    |
| Resolution time     | The issue is in a selected status                                      |

`New` and `On You` always count, and closed statuses never do. Add other statuses, including your custom statuses, to keep the timer running in them. Leave a status out to pause the timer while an issue sits in it. For example, leave out `On Hold` so resolution time pauses while you wait on an engineering fix.

Without counting settings, first and next response time count in `New` and `On You`. Follow-up and resolution time also count in `On Customer`.

#### Start counting time when the conversation becomes a ticket

When this is enabled, timers still run while an issue is a conversation, but they restart when the conversation becomes a ticket. A reply sent before the conversation became a ticket no longer counts as the first response; the first reply after it does.

{% hint style="info" %}
Counting settings are available on the Enterprise plan.
{% endhint %}

### Team SLAs

Team SLAs allow setting SLAs on how long a team is assigned to an issue. These run independently from issue SLAs. Create them with **Add Team SLA** on the **Team SLAs** tab of the [SLAs page](https://app.usepylon.com/settings/slas) or from [trigger templates](https://app.usepylon.com/settings/slas/create?groupID=b929bfac-4b9a-475d-9075-0e13074d79f3\&category=teamSla). Team SLAs are visible in [analytics](https://app.usepylon.com/analytics?tab=general).

Team SLAs are available on the Enterprise plan.

<figure><img src="https://982123570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9hXBoCTTNw5flARlUVJf%2Fuploads%2FHZuGLkerHusj1HEJLqxi%2FCleanShot%202025-11-09%20at%2016.20.55%402x.png?alt=media&amp;token=6b8f81df-d6af-47eb-a717-6359fcbc42de" alt="" width="375"><figcaption></figcaption></figure>

### SLAs vs Team SLAs

The key difference is what each SLA measures. Issue SLAs measure the customer’s overall experience. For tickets, timing normally begins when the conversation becomes a ticket; for non-ticket conversations, it begins with the first qualifying customer message. Team SLAs measure a specific team’s performance and start when the SLA is applied or the issue is assigned to that team, whichever happens later. This prevents a team from being penalized for\
time before it owned the issue.

Issue SLAs should be used when:

* You want to measure the overall customer experience from issue creation to resolution.

<figure><img src="https://982123570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9hXBoCTTNw5flARlUVJf%2Fuploads%2FMEAFs15mrhVEfnGeTsSR%2FScreenshot%202025-11-12%20at%2011.06.19%E2%80%AFAM.png?alt=media&amp;token=35f95a4c-ad54-4fd4-89c0-adcc760653a7" alt=""><figcaption></figcaption></figure>

Team SLAs should be used when:

* You want to measure individual team performance separately from the overall customer experience.

<figure><img src="https://982123570-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9hXBoCTTNw5flARlUVJf%2Fuploads%2FsPTn5EzHXpgI0KosxQTo%2FScreenshot%202025-11-12%20at%2011.01.21%E2%80%AFAM.png?alt=media&amp;token=1c864699-0852-4231-9b12-789a92791a35" alt="" width="311"><figcaption></figcaption></figure>

### Active Time

Active time measures hands-on effort per person, per issue, rather than elapsed time. It is configured in the same place as SLA counting, **Settings > Workflows > SLAs > Counting settings**, and appears in the SLAs sidebar module on every issue. Active time is available on the Enterprise plan. See [Active Time](/pylon-docs/support-workflows/slas-and-timers/active-time.md) for the full behavior.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.usepylon.com/pylon-docs/support-workflows/slas-and-timers.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.