SCORM Tracking Repair — $350 Flat, Verified in SCORM Cloud
Learners finish the course and stay "incomplete." Scores never post. We find the actual cause, fix the package or the LMS, and prove the fix with logs before we call it done.
Flat-rate SCORM repair
The course runs. Nothing records. We fix that.
This is the single most common support ticket in e-learning, and the most misdiagnosed. The course plays perfectly — video, quiz, everything — and then the gradebook shows nothing. It is almost never random. There is a specific, findable cause, and finding it is exactly what we do all day.
$350 flat per package. Not hourly, no meter running. The only other flat-rate SCORM repair specialist we've found starts at $650; agencies quote it as open-ended hourly work and take two weeks to reproduce the bug. Fixing five or more? The 5-pack is $1,400 — $280 each.
Get a free SCORM tracking diagnosis
We reply within 1 business hour. Prefer to talk? (615) 396-7139.
Fix it yourself first, if you can
The 7 real reasons SCORM stops tracking
Before you pay us or anyone else, check these seven. They cover well over 90% of the broken packages that cross our desk. Every one of them is diagnosable with a zip utility, a text editor, and a free SCORM Cloud trial account.
1. SCORM version mismatch — 1.2 content in a 2004 slot, or vice versa
SCORM 1.2 content looks for a JavaScript object named API in the launching window's parent chain. SCORM 2004 looks for API_1484_11. They are different objects with different method names (LMSInitialize vs Initialize). If the package targets one spec and the LMS launches it as the other, the handshake never happens and nothing records — not even an attempt start.
Check it yourself: unzip the package and open imsmanifest.xml. Find the element — it will say 1.2 or something like 2004 4th Edition. Compare that to what your LMS thinks it imported. If they disagree, re-import or republish. Done.
2. lesson_status vs completion_status mapping
SCORM 1.2 has one status field, cmi.core.lesson_status, with six allowed values: passed, completed, failed, incomplete, browsed, not attempted. SCORM 2004 split it into two fields — cmi.completion_status and cmi.success_status — and that split is where most "learner finished but shows incomplete" tickets come from.
Your authoring tool has a setting like "report status as: Passed/Incomplete, Passed/Failed, Completed/Incomplete, Completed/Failed." If the course reports passed but the LMS completion rule is watching for completed, the learner finishes and stays incomplete forever. Neither side is malfunctioning. They're just not speaking the same dialect.
On Moodle™ you can see exactly what the package reported: the raw calls land in the mdl_scorm_scoes_track table, or more conveniently in the SCORM activity's Reports → Track details view. Look at what arrived, then align either the authoring tool's tracking option or the LMS rule to match it.
3. Mastery-score overrides
SCORM 1.2 manifests can carry an adlcp:masteryscore value. Many LMSs — Moodle's 1.2 player among them — will recompute passed/failed from the raw score whenever a mastery score is present, overriding whatever status the course reported. The classic failure: a survey or policy-acknowledgment course with no quiz, exported with a leftover masteryscore="80". The course says "completed," the LMS sees a score of 0 against a mastery of 80, and flips the learner to failed.
Fix: open imsmanifest.xml, delete the adlcp:masteryscore line, and re-zip — making sure imsmanifest.xml ends up at the root of the zip, not inside a folder. Or disable the mastery override setting if your LMS exposes one.
4. suspend_data overflow (the sneaky one)
SCORM 1.2 caps cmi.suspend_data — the string the course uses to remember where you left off — at 4,096 characters. That limit was set in 2001. A modern 60-slide Storyline course tracking variables and interaction states blows past 4KB without trying. Strict LMSs reject the oversized LMSSetValue with error 405; permissive ones silently truncate. Either way, resume breaks, and the final status write often gets lost in the same failure.
This is the annoying part: the course works fine in short tests and only fails for learners who get deep into it, so it looks intermittent. It isn't. Fixes: republish as SCORM 2004 (the limit rises to 64,000 characters in 4th Edition), enable suspend-data compression in your authoring tool, or reduce how many slides and variables you track.
5. API discovery failures in nested iframes
The SCO finds the LMS API by walking up the window.parent chain and checking window.opener. Anything cross-origin in that chain — content served from a CDN on a different domain, a corporate portal embedding the LMS in its own iframe, a reverse proxy that rewrites one hostname but not the other — and the browser blocks the walk cold. The telltale sign: the package tracks perfectly in SCORM Cloud but goes silent in your environment, sometimes with an "Unable to acquire LMS API" alert, often with nothing at all.
Fix: serve the content same-origin with the LMS, remove the extra embedding layer, or launch in the LMS's own player window instead of a portal iframe. This one is an infrastructure problem wearing a SCORM costume.
6. LMS-side grading method misconfiguration
Sometimes the package is innocent. In Moodle, a SCORM activity's Grading method (Learning objects / Highest grade / Average / Sum) plus its completion conditions can demand data the package never sends. Set "require minimum score" on a course that only reports status, and no learner will ever complete it. We think the Moodle defaults deserve some blame here — "Highest grade" assumes a score exists, and plenty of compliance content doesn't send one. If your package reports status only, set grading to Learning objects and build completion rules on status, not score.
7. Packages exported with a broken imsmanifest
The unglamorous stuff: imsmanifest.xml zipped inside a subfolder instead of at the root (Moodle rejects the upload outright for this); the resource marked adlcp:scormtype="asset" instead of "sco", which launches the content as a dumb page with no tracking wired up at all; a launch href pointing at a file that was renamed; a missing schemaversion. Two minutes with a text editor finds all of these — most shops skip that step because reading XML is tedious. We don't.
Honest number: roughly a third of the "broken" packages sent to us aren't broken. The LMS configuration is. That's why the diagnosis is free and happens before you commit to anything — and if one LMS-wide setting turns out to be breaking ten packages, that's one repair, not ten. We'll say so.
If tracking broke right after you moved platforms, the migration itself is the more likely suspect — attempt data and activity settings get mangled in transit. That's a different fix; see our LMS migration service and its zero-data-loss guarantee.
Get a free SCORM tracking diagnosis
Send the package, we'll tell you which of the seven it is. Reply within 1 business hour.
How the $350 works
Diagnose, repair, verify — with logs, not vibes
Step 1 — Diagnose
We upload your package to SCORM Cloud, the industry's reference implementation, and run it with full debug logging turned on. That log shows every API call the course makes — every LMSSetValue("cmi.core.lesson_status", ...), every error code it gets back. Then we run it in your LMS with the test login you give us and compare. Between the two logs and the manifest, the cause names itself. You get that diagnosis in writing, free, whether or not you hire us.
Step 2 — Repair
Depending on the cause: we edit the manifest directly and re-zip, fix the status mapping and republish settings, patch the launch wrapper, or hand you an exact, screenshotted list of LMS settings to change. If the fix belongs in your authoring tool's export settings, we document it so your next twenty exports come out right too.
Step 3 — Verify
A full tracked run in SCORM Cloud showing status and score posting correctly, then a second full run in your LMS as a test learner. You get both logs and a short write-up. If it doesn't verify, we're not done — the flat fee covers getting it working, not attempting to.
Logistics
What we need, what it costs, how long it takes
Two things, usually: the SCORM .zip exactly as exported (we almost never need your Storyline or Captivate source files) and one test learner login to your LMS, plus which LMS and version you're on.
| Service | Price | Turnaround |
|---|---|---|
| Free tracking diagnosis | $0 | 1 business day from receiving files |
| SCORM repair, single package | $350 flat | 2–3 business days |
| SCORM repair, 5-pack | $1,400 ($280 per package) | About one week |
Working with a training vendor's content? We fix the published package without touching their source, and we'll handle learner data under FERPA-aware procedures if your courses involve student records — details on our compliance page. Recurring SCORM triage is also built into our Standard and Premium care plans, and hosting clients on managed Moodle hosting get us already inside the stack when something misbehaves.
Questions we actually get
SCORM repair FAQs
Why does my SCORM course show "incomplete" even after learners finish?
Nine times out of ten it's a status-mapping mismatch: the course reports "passed" while the LMS completion rule watches for "completed" (or the reverse), or a leftover mastery score is overriding the reported status. Check your authoring tool's "report status as" setting against the LMS completion condition first. In Moodle, the Track details report shows exactly what value the course sent.
Do you need our Storyline or Captivate source files?
Usually not. Most repairs happen in the published package — the manifest, the launch files, the wrapper JavaScript — or in LMS settings. If the fix genuinely requires republishing (suspend_data overflow sometimes does), we'll give you the exact export settings to use, or work from your source if you'd rather hand it over.
Which LMSs do you work with?
Any LMS that speaks SCORM. Moodle is our home turf, but we regularly fix tracking on Canvas, Blackboard, Brightspace, Cornerstone, TalentLMS, and SCORM Cloud dispatch setups. The diagnosis method is the same everywhere: compare the SCORM Cloud API log against your LMS's behavior and the gap points at the culprit.
Should I publish SCORM 1.2 or 2004?
If your LMS supports 2004 well, publish 2004 4th Edition — you get the 64,000-character suspend_data limit and the cleaner completion/success status split. Publish 1.2 only when a target LMS demands it, and if you do, keep courses short or compress suspend data so you stay under the 4KB cap. "1.2 because it's more compatible" is advice from 2010; test your actual LMS instead.
What if the problem is our LMS, not the package?
Then the diagnosis says so, for free, and one configuration fix often repairs every affected package at once — we charge for that as one repair, not per package. If the misconfiguration traces back to a botched platform move, we'll tell you that too and point you at our migration review rather than selling you five SCORM repairs that won't hold.
How fast is turnaround?
Diagnosis within 1 business day of receiving your .zip and test login. Most single-package repairs finish in 2–3 business days; a 5-pack takes about a week. If something is genuinely on fire — a compliance deadline, an audit — say so and we'll tell you honestly whether we can compress that.
Get a free SCORM tracking diagnosis — $350 flat if you hire us to fix it
Reply within 1 business hour, or call (615) 396-7139. Sternfast, a Vbounds LLC company — Nashville-based, working with teams across the US.