Ticket metric event types reference

The List Ticket Metric Events endpoint returns the following types of metric events:

• Activate events
• Pause events
• Fulfill events
• Apply SLA events
• Breach events
• Update status events

Activate events

Each metric has an activate event that represents when the clock starts running for that particular metric. In the case of the reply_time metric when instance_id is 1, as well as the agent_work_time and requester_wait_time metrics, the time usually corresponds to the time the ticket was created.

Activate events are also used to indicate that a ticket metric is no longer paused or, in some cases, fulfilled.

You'll see an activate event for all metrics, regardless of whether the ticket is being measured by an SLA policy or whether the metric has a set target.

Example:

{
  "id": 123456,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "activate",
  "time": "2015-08-27T08:00:00Z"
}

Pause events

A pause event represents a ticket metric that hasn't been fulfilled yet but was paused according to the metric's conditions. Examples:

• the requester_wait_time metric is paused when the ticket status is pending
• the agent_work_time metric is paused when the ticket status is pending or on-hold

When a ticket metric is un-paused (for example, when the ticket goes back into the open status), another activate event is created.

Pause events are recorded for all metrics, regardless of whether the ticket is being measured by an SLA policy or whether the metric has a set target.

The following example shows a pause event followed by an activate event:

{
  "id": 123466,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "pause",
  "time": "2015-08-27T08:30:00Z"
},
{
  "id": 123476,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "activate",
  "time": "2015-08-27T09:00:00Z"
}

Fulfill events

A fulfill event represents a ticket that was updated in such a way that the end state of that metric has been fulfilled. For example, for the reply_time metric, a fulfill event occurs when a public agent replies for the first time by adding a comment to a ticket. For the requester_wait_time metric, a fulfill event occurs when the ticket's status is changed to solved. A fulfill event doesn't mean that the ticket achieved any SLAs. It simply means that the metric's end conditions have been satisfied.

It's possible for a ticket metric to be fulfilled and then un-fulfilled. For example, the requester_wait_time metric is fulfilled when the ticket is solved. If the ticket is reopened, the requester_wait_time metric starts where it left off.

Fulfill events are recorded for all metrics, regardless of whether the ticket is being measured by an SLA policy or whether the metric has a set target.

The following example shows a sequence of fulfill and activate events for a ticket when its status was set to solved, to open, and then back to solved:

{
  "id": 123486,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "fulfill",
  "time": "2015-08-27T10:30:00Z"
},
{
  "id": 123496,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "activate",
  "time": "2015-08-27T11:00:00Z"
},
{
  "id": 123506,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "fulfill",
  "time": "2015-08-27T12:00:00Z"
}

Apply SLA events

The apply_sla event type designates that a particular metric on a particular ticket is now measured by a target on an SLA policy. If the apply_sla event is not present for a ticket and metric, the metric isn't currently measured by an SLA policy. An apply_sla event occurs when an SLA policy is applied to a ticket or when a SLA policy or target changes on a ticket.

Each apply_sla event includes a sla property describing the applied policy. See the sla property in the API docs.

The following example shows a typical apply_sla event:

{
  "id": 123457,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "apply_sla",
  "time": "2015-08-27T08:00:00Z",
  "sla": {
    "target": 60,
    "business_hours": true,
    "policy": {
    "id": 531,
    "title": "Main Policy",
    "description": "Measure all tickets"
    }
  }
}

Breach events

A SLA target was breached.

You'll never receive a breach event if you didn't first receive an apply_sla event. Metrics not measured by an SLA policy will never have a breach event.

Breach events are recorded before a breach, so all breach events include a deleted property (see the deleted property in the API docs). The deleted property is always false and can be ignored as it is no longer used.

The following example shows a typical breach event:

{
  "id":  123479,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "breach",
  "time": "2015-08-27T09:30:00Z",
  "deleted": false
}

Update status events

The update_status event typically occurs alongside fulfill events. These events are used to provide information on the current value of the metric at the time of the fulfill event. To do this, each update_status event includes a status property. See the status property in the API docs.

The following example shows a typical update_status event:

{
  "id": 123480,
  "ticket_id": 987,
  "metric": "requester_wait_time",
  "instance_id": 1,
  "type": "update_status",
  "time": "2015-08-27T09:30:00Z",
  "status": {
  "calendar": 60,
  "business": 60
  }
}