@EdgarIvanV

SLA Escalation actions are processed by the Pega ProCom standard agent ServiceLevelEvents

https://docs-previous.pega.com/system-administration/86/pega-procom-agents

This will pick up SLA entries from the queue (class System-Queue-ServiceLevel) every few seconds depending on the Agent Schedule (and runs on each node in your system). Since it is based on periodically picking entries from a queue, it will never process in real time. There will always be a slight delay because of the agent schedule.

If it is taking longer to process than you have given in the SLA rule, this can happen for a few reasons:

1. Agent Schedule config has been modified (maybe somebody has been changing it to pick records every 30 minutes instead of every few seconds? Maybe they switched off the agent in Admin Studio?)

2. High Load on the SLA agent.The SLA queue System-Queue-Service level either has a very high number of entries in it and the agent is taking a long time to process these records, so your case is getting delayed due to high volume of cases. Or there could be particular processes that are being executed by the SLA mechanism which are very intensive and are taking up resources and slowing the processing down (like generating giant batch files for example). If it's a test system you can try clearing the SLA queue table. If it is production you will need to investigate why the volume is so high.

3. The case to be cancelled is locked. If you or another user has the case open on an assignment then the lock is held. The SLA cannot process entries when the lock is held by another requestor. It will automatically retry later. I believe the default lock timeout is 30 minutes, so if somebody locked the case, then forgot about it, the SLA wouldn't be able to process for at least 30 minutes. You can see in the logs if the SLA fails to execute due to lock issues.