# Apex CPU timeout: has it been increased for synchronous transaction?

I was just trying out some code and accidentally found that the code was running more than 10s. I was able to make the code run (anonymously from dev console) upto 15 sec beyond which it timed out. Just wanted to understand if salesforce has increased the Apex CPU timeout limit for Sync operation.

DateTime firstDate = System.now();
system.debug('before loop ==> '+ system.now());
//THis will iterate for 15 seconds.
do{
//do nothing
}while(system.now() < secondDate);

system.debug('after loop ==> '+ system.now());


Results

before loop ==> 2018-06-16 15:52:58
after loop  ==> 2018-06-16 15:53:13  //There is a 15 sec difference


Comparing the datetime between the start and end of your execution isn't really a reliable way to determine how close you are to the limits.

The documentation on current governor limits tells us that for a synchronous transaction, the total maximum time allowed is 10 minutes (600 seconds).

Of that, a transaction can consume 10,000 milliseconds (10 seconds) of CPU time, and if you have callouts, those can consume up to a total of 120 seconds. Time spent actually in the database when you make a query doesn't count towards the CPU governor limit.

A more reliable indicator would be to track the CPU limit, which you can do by calling Limits.getCpuTime()

That said, the CPU limit is one that has been a "soft" limit. Salesforce won't necessarily cut you off if you exceed the CPU limit (depending on several factors, like current load on your pod), but they guarantee that your transaction will not be cut off if it consumes less than the prescribed 10,000 ms (assuming you don't run into exceptions or other limits, that is).

There was also session at Dreamforce last year (DF 2017) on Salesforce platform limits that suggest that the CPU limit (and I believe a few others) are going to start moving towards a 3-tier monitoring system. One is a threshold under which no action is taken (akin to governor limits today), one is an absolute maximum threshold, and then the limit in the middle depends on how often and by how much you exceed the low threshold.

The talk of these threseholds begins at 24:36 in the video. 29:17 begins the discussion of when Salesforce plans to roll that out (should be here now that Summer '18, API v43.0 has been released)

• Thanks for the link to the DF presentation that talks about Soft Limits. Has any of that surfaced yet? – Keith C Jun 16 '18 at 22:49
• @KeithC Based on the presentation, the soft limits should be available now, but I haven't looked through the release notes to confirm. My work days of late have been busy with adapting the architecture for a custom integration due to receiving additional requirements after the initial design was implemented (which sounds par for the course for integrations). – Derek F Jun 17 '18 at 2:14
• With 15 sec time difference, I am getting an CPU usage time of 14142ms. Anyways, thanks for the link, that helps! Will need to check if we are notified if we frequently go beyond the 10s limit. One another question, from what I understand looping is a CPU intensive task and since we have set the condition that the loop has to run for 15 sec, how is it that the CPU timeout is less than that? – Sam Jun 17 '18 at 2:34
• You're only guaranteed 10,000 ms, but "if the system feels like it," you can easily get to 20,000 or more ms. You'll want to optimize your code, and/or choose to go for a future/queueable/batchable operation, but it's definitely not a hard limit. Actual execution limits are dependent on system load. – sfdcfox Jun 17 '18 at 3:26
• @DerekF Don't see any mention in the Summer '18 release notes of the concept... – Keith C Jun 17 '18 at 10:07

My understanding is that the timeout is not always enforced, but may well be enforced in a production environment. So you should work on your algorithm to get the time down well below 10 seconds.

Others may know of links to documentation that explains this better; right now I can't find such documentation.