Moodle SCORM Tracking Problems: Why Completions Fail and How to Fix Them

If you manage SCORM courses in Moodle, you’ve probably seen this: a learner finishes a course, but Moodle doesn’t mark it as complete. The gradebook shows nothing. The completion report is blank. The learner swears they finished. And you have no idea what went wrong.

This is the single most common support issue in Moodle forums related to SCORM. Threads about it go back years. The frustrating part is that the causes are spread across three different systems (your authoring tool, the SCORM package itself, and Moodle’s configuration), and a misconfiguration in any one of them can silently break tracking. No error. No warning. Just a blank checkbox where a completion should be.

This guide walks through every major cause and the fix for each.

Cause 1: Moodle does not support SCORM 2004

This is the most common source of confusion. Moodle’s built-in SCORM player supports SCORM 1.2. It will accept and launch SCORM 2004 packages, but Moodle does not support SCORM 2004. This isn’t a partial-support situation. According to Moodle’s own documentation (MoodleDocs SCORM FAQ): development on native SCORM 2004 support has stopped, and bugs reported against SCORM 2004 in the Moodle tracker are closed as “won’t fix.” Some packages appear to work because parts of the basic API were partially implemented years ago, but tracking data may not report correctly, sequencing won’t function as designed, and there’s no path to fixing it.

The fact that Moodle will silently accept a SCORM 2004 package and launch it without warning you that tracking may not work is, honestly, the worst part. You find out something’s wrong when completions don’t show up.

Fix: Publish your courses in SCORM 1.2 for Moodle. If you’ve been using SCORM 2004 and experiencing tracking issues, re-export in 1.2 and re-upload. In most authoring tools (Articulate Storyline, Adobe Captivate, iSpring), this is a single setting change in the publish dialog. That it’s an easy fix doesn’t make it less frustrating that you had to discover it this way.

Cause 2: Completion criteria mismatch between authoring tool and Moodle

SCORM completion is set in two places: inside the course (via the authoring tool) and inside Moodle (via activity completion settings). If these don’t match, completions won’t register.

Example: Your Storyline course is configured to report completion based on “quiz passed.” But in Moodle, activity completion is set to “Require view.” Moodle sees that the learner viewed the activity but never receives a passed/completed status from the SCORM data model, because it’s looking at the wrong signal.

Another common mismatch: the authoring tool sends a completion status of “passed,” but Moodle’s activity completion is looking for “completed.” In SCORM 1.2, these are distinct values (cmi.core.lesson_status can be “completed,” “passed,” “failed,” or “incomplete”). In Moodle, the “Require status” setting needs to match what your course actually sends.

Fix: Check three settings and make sure they align:

1. In your authoring tool: what triggers completion? (slide views, quiz pass, or both?)
2. In the SCORM package settings in Moodle: what’s the “Required status” set to? (Completed, Passed, or either?)
3. In Moodle’s activity completion settings: is it set to require view, require grade, or require status?

If your course sends “passed” on quiz completion, set Moodle to require “Passed” status, not “Require view.”

Cause 3: Conflicting activity completion settings in Moodle

Moodle lets you stack multiple completion criteria: require view AND require grade AND require passing grade. This sounds like thoroughness. In practice, it creates conflicts.

A forum post on Moodle.org describes this pattern: “Require grade” and “Require passing grade” are both ticked. The result is unpredictable: some learners get marked complete, others don’t, even with identical quiz scores. If you’ve ever stared at a completion report wondering why it’s random, this might be your answer.

Fix: Use one completion criterion, not multiple. For SCORM courses with a quiz, “Require passing grade” alone is usually sufficient. For SCORM courses without a quiz, “Require view” works. Don’t combine criteria unless you’ve tested the specific combination with your SCORM package.

Cause 4: Adobe Captivate-specific settings for Moodle

Captivate courses are particularly prone to Moodle completion issues because Captivate has its own LMS-specific publishing settings that must be configured correctly.

Common Captivate problems in Moodle: Captivate defaults may not include “Set exit to normal after completion,” and without this, some Moodle versions don’t receive the session-end signal. If “Send data on every slide” is enabled, data volume can exceed Moodle’s SCORM data string limits, causing silent failures. And if Captivate’s LMS setting isn’t set to “Moodle” specifically, the completion variables may not be written correctly.

Fix: In Captivate’s Quiz Preferences > Reporting: set LMS to “Moodle,” set Standard to SCORM 1.2, set completion criteria to match your intent (quiz pass or slide views, not both unless you’ve tested it), and consider unchecking “Send data on every slide” to reduce data volume.

Cause 5: Moodle SCORM Standards Mode data limits

Moodle has a “SCORM Standards Mode” setting that limits the amount of data a SCORM package can send. When enabled (the default), packages that send large amounts of interaction data (detailed quiz responses, many slide views) can exceed the limit. The data gets silently truncated, and the completion status may never be written.

Fix: In the SCORM activity settings in Moodle, uncheck “SCORM Standards Mode.” This allows the package to send more data than the default limit. This setting is often overlooked because the name doesn’t suggest it relates to data size limits. It’s one of those Moodle settings that you only learn about when something breaks.

Cause 6: Browser caching and network interference

SCORM tracking depends on JavaScript running in the browser and communicating with the Moodle server. Anything that interrupts that communication can break tracking: aggressive browser caching can serve stale JavaScript that doesn’t send completion data; VPN connections or endpoint security software (CrowdStrike, Zscaler, GlobalProtect) can block the API calls; browser extensions that block scripts or modify network requests can interfere.

This cause is intermittent, which makes it especially maddening. The same course works for some learners and fails for others, with no pattern you can reproduce.

Fix: Test with a clean browser profile (no extensions, cleared cache). If tracking works in a clean environment, the issue is client-side. Check with your IT team about VPN or EDR software that might be interfering with LMS communication.

Cause 7: CRON job not running or delayed

Moodle’s completion processing depends on the CRON job. If CRON isn’t configured to run frequently, there can be a significant delay between a learner completing a course and Moodle updating the completion status. In some cases, if CRON fails entirely, completions are never processed.

Fix: Verify that Moodle’s CRON job is running at 1-minute intervals. Check the CRON status in Site Administration > Server > Scheduled Tasks.

When the complexity isn’t worth it

Look at the seven causes above. SCORM version compatibility. Completion criteria alignment across two systems. Authoring tool settings that must be configured per-LMS. A data limit setting whose name gives no indication of what it does. Browser and network variables you can’t control. A CRON job you might not know exists.

Every one of these is solvable. But none of them should be your problem if all you’re trying to do is deliver a training course and know who finished it.

The common thread is that SCORM tracking in Moodle requires multiple systems to be perfectly aligned: the authoring tool’s publish settings, the SCORM package’s internal data model, Moodle’s SCORM player settings, Moodle’s activity completion settings, and the server and network environment. When one setting is wrong, tracking breaks silently. There’s no error message. The course plays normally. The learner sees no indication that anything failed.

For a lot of training teams, Moodle was chosen because it was the LMS that was available, not because it was the best tool for delivering SCORM content and tracking completions. If that describes your situation, there’s a simpler path.

A different approach

OpenSCORM is a SCORM hosting platform built specifically for the use case that causes most of the problems above: upload a course, share a link, track who completed it.

There’s no SCORM version compatibility to debug. OpenSCORM supports SCORM 1.2 and xAPI natively. There’s no completion criteria mismatch to troubleshoot, because the platform handles the SCORM runtime directly. No authoring-tool-specific LMS settings. No data string limits. No CRON dependency.

You upload a SCORM package. You share an enrollment link. Learners take the course. Completions are tracked. That’s the whole workflow.

Plans start at $30/month with flat-rate pricing: no per-registration overages, no bill surprises. There’s a free tier for evaluation.

If you’ve spent hours chasing completion tracking bugs across Moodle settings pages, forum threads, and authoring tool configurations, you know what that time costs. OpenSCORM exists so that time goes to zero.

The Moodle integration page walks through how the two approaches compare side by side.