FORCED_COMMIT_TIME value of 60000 (60k)

When publishing a Storyline 2 course for LMS, the configuration.js file has a setting "FORCED_COMMIT_TIME" which is set to "60000".  

Am I safe to assume that this is the number of milliseconds between regular LMSCommit() events that Storyline 2 triggers (unless explicit ones are issued such as after an assessment)?

This value equates to 1 minute however I seem to see LMSCommit() events running every 10 minutes.  Is there a miscalculation on the number conversion here?  Am I missing something else?

Also, having searched the course for the value "FORCED_COMMIT_TIME" (all files), there is only that one occurrence of the value.  Is the value actually being used?

Thanks, Chris

38 Replies
Chris Walsh

Thanks Ashley,

We've got our own LMS which is hosting SL2 courses.  We're getting occasional cases where users complete the course (got a printout of the certificate etc.) but we've not got a record on our LMS.  

We've noticed that if there is a communication failure writing the SCORM data back via our API Adaptor, the exception is caught (in our adaptor) and logged but we're not alerting the user to the problem.  We're testing a fix for this (including a retry option).  

However we're unsure about whether the heartbeat LMSCommit()s from SL2 are being fired or not and if they are whether they are doing so at the frequency given by FORCED_COMMIT_TIME.  Certainly they don't appear to be happening as frequently as 60000ms (=1 minute) - which is a value which we would be happy with BTW.



Chris Walsh

Thanks Phil.  I know we can change the value (a simple edit to the js file) and why you may not want to set the value too high or low.  I'm just questioning whether it is actually being used by the course and if it is, whether it is treating the units as milliseconds.  

The reason I question it is because I can't see anywhere where any JavaScript actually reads this value and the rate of LMSCommit() don't seem to tally with the value set.

Chris Walsh

Okay, I think I can give a clearer example of the problem.

I have an LMS-published SL2 course with default configuration.js settings including  FORCED_COMMIT_TIME=60000 (60000ms = 1 minute)

On my LMS, whenever an LMSCommit() call is raised by the course, I log the time into a log window.  I run the course and let it sit idle.

My log looks like this...


Clearly 60000ms = 1 minute does not equal (11:12:52 - 11:02:52) = 10 minutes, so either SL2 is incorrectly interpreting the 60000 as 60000 hundreds of a second = 10 minutes or it is ignoring the value completely and using a default/hardcoded value (which is what I suspect as I cannot see any other reference to FORCED_COMMIT_TIME in any other Javascript file in the course)).

Is there a means for me to raise this with Articulate at a technical level?


Ashley Terwilliger-Pollard

Hi Chris,

I double checked with our team, that the 60000 = 10 mins in Articulate for the LMS Commit time, and you'll see another thread with that time mentioned here

If you'd like to see the data we're passing to your LMS, I'd recommend enabling LMS debug mode as detailed here. If you're still having difficulty with it and would like to investigate further with our Support Engineers we're happy to do so and you can reach out to them here. 

Chris Walsh

Hi Ashley,

Thanks.  That has explained a lot of what is going on (despite being related to Studio '09).

I've checked the lms.js file that SL2 packages up with the course and found:

setInterval("ForceCommit()", 600000);


  1. SL2 uses a 600000ms (10 minute) interval rather than a 60000ms (1 minute interval)
  2. SL2 is NOT using the value in configuration.js despite it making sense to do so.
  3. The value is hardcoded in the code rather than in configuration.js.
  4. There is no option (such as setting the value to 0 like the comment suggests in configuration.js) to switch off auto-committing.  One would have to comment out the line of code in lms.js.

I can propose a change request for the developers to:

  1. Amend configuration.js to set the value of FORCED_COMMIT_TIME to 600000 (10 minutes) in line with a 10 minute interval currently hard coded in lms.js.
  2. Amend lms.js to make use of the FORCED_COMMIT_TIME rather than hard coding the value.

This will make it a lot easier (and a lot less misleading) to course builders who wish to customise the forced commit time.



Chris Walsh

Hi, we're two years on and we're still seeing freshly published courses committing every 10 minutes instead of every 1 minute despite FORCED_COMMIT_TIME = "60000";

We've shed a bit more night on it though:

  • Running a course in Google Chrome shows an auto- ommit every 1 minute
  • Running a course in IE11 shows an auto- ommit every 10 minutes

We've tried two different courses and it's the same.  

So why is IE11 different to (say) Chrome?  Well IE11 is running the course in "Flash" whereas Chrome is running it in native HTML5. 

So we've disabled Flash in IE11 to run the Native HTML5 and we then got the correct 1 minute auto-commit.

So this might be a bug in the Flash framework.  Are you seeing the same situation?  Thanks.


Ashley Terwilliger-Pollard

Hi Chris,

I know this discussion has gone on for some time, but I wanted to confirm what version of Storyline you're using? We had an issue in Storyline 360 where the HTML5 LMS output sends a status to the LMS even if we set var FORCED_COMMIT_TIME = from 60000 to 0. That was fixed in Update 16, and it'll be fixed in the next update of Storyline 3 as well.

If you are still seeing something odd in your files, could you connect with our Support team so that we can take a look! 

Alyssa Gomez

Hi Dave,

Really sorry you're running into this, as well. We had an issue in Storyline 360 where the HTML5 LMS output sends a status to the LMS even if we set var FORCED_COMMIT_TIME = from 60000 to 0. That was fixed in Update 16, and it'll be fixed in the next update of Storyline 3 as well.

We'll keep you posted and let you know as soon as that fix is released!

Crystal Horn

Hey Dave. I'm excited to let you know that we just released update 5 for Storyline 3! It includes new features and fixes - check them all out here.

One of the fixes addresses an issue where HTML5 output sends a status to the LMS even if we set var FORCED_COMMIT_TIME = from 60000 to 0.

Here’s where you can download and install the latest version of Storyline 3. Let me know how you make out!

Nathan Leavitt

Hi Alyssa, thanks for writing back. Sorry for being vague in my former post. Yes, I'm seeing a problem with Rise that's very similar to this conversation about Storyline. For the purpose of establishing some context, here's how Storyline works:

Storyline calls the ForceCommit() function at an interval that's defined by the   FORCED_COMMIT_TIME variable in configuration.js. With Storyline, even if the communication to the LMS is severed after some time has passed, I can still see from the LMS communication log that data was written back to the LMS up to the point where the communication was severed. It took place every 60 seconds, as defined by the FORCED_COMMIT_TIME variable. This is great! This is as it should be.

Rise does not have the same behavior. Even though the scormdriver.js file declares the FORCED_COMMIT_TIME variable, it is not being utilized even if it's set to 60000 (the same default value of the Storyline variable).

This behavior in Rise is the same as the original post by by Chris Walsh. (But, of course, the original post was for Storyline - which now works as expected.)

Alyssa Gomez

Hi, folks! I wanted to share an update for anyone following along in this discussion.

Our team found that Rise 360 courses are not sending keep-alive messages to the LMS, even if the FORCED_COMMIT_TIME variable is changed the value from 0 to 60000.

If we get an update on this issue, we'll pass it along to you. Thanks for bringing this to our attention!

Ian Crossley

Thanks Alyssa. We are embedding the majority of the learning experience within an iframe within Rise, so there isn't much navigation happening from lesson to lesson. As a result, exactly as you said, some learners are timing out and losing their progress, therefore we were hoping to use the FORCED_COMMIT_TIME variable to periodically force LMS Commits to happen in the background.