Multiple quick succession updates from Tivoli (possibly any integration), in conjunction with a user action on a record, can result in multiple task_sla records running against an incident. On the surface it seems that the task_sla is being created, even though the start condition does not apply. Processing that many updates that are occurring, sometimes within the same second, is likely a rare timing issue.

Create a new SLA (using the Default SLA Workflow):

Start: Priority is 2 High AND Assignment Group is Network AND Incident state is Active.
Stop: Incident State is Resolved.
Pause: Priority is not 2 High OR Assignment Group is not Network OR Incident state is Awaiting User Info.

1. Create a new incident and meet the start conditions.
2. Write a loop to go through and update the incident (simulate getting multiple quick succession updates from an integration).
3. In another window (while the below is processing) open the incident and mark it Resolved (to meet the Stop condition).

Reload the form and note that you will have two task_sla records. The second one seems to have started at the same time the incident was resolved. This second task_sla has been known to show a variety of stages, such as Achieved, In Progress, and even Breached at times. The second task record should have never been created.

Script used to handle steps 1 and 2:

var inc = new GlideRecord('incident');
inc.initialize();
inc.assignment_group.setDisplayValue('Network');
inc.priority = 2;
var inc_sys_id = inc.insert();
gs.sleep(3000);

var i1 = new GlideRecord('incident');
i1.get(inc_sys_id);
i1.incident_state = 2;
i1.comments = 'Update to Active - SLAs should start';
i1.update();
gs.sleep(500);

for (var i = 1; i <=100; i++ ) {
var i1 = new GlideRecord('incident');
i1.get(inc_sys_id);
if (i1.incident_state != '6') {
i1.comments = ("Update " + i);
i1.update();
} else {
for (var j = 1; j <=2; j++) {
var i2 = new GlideRecord('incident');
i2.get(inc_sys_id);
i2.comments = ("Update " + i + "(" + j + ")");
i2.update();
}
break;
}
}

Set the Process SLAs business rule to run after instead of async.

This reduces the chance of multiple SLAs being attached by preventing multiple SLA actions from being queued for execution.

For a complete solution, change to the 2011 SLA engine, as described in the product documentation topic Legacy SLA engines.