SCORM Tracking Repair — Flat-Rate, 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.
- A fixed, flat price per package — no hourly meter, no two-week reproduction.
- Diagnosed with evidence — the SCORM Cloud API log, not guesswork.
- Free diagnosis first — a third of "broken" packages are really an LMS setting.
Flat-rate SCORM repair
The course runs. Nothing records. We fix that.
The most common support ticket in e-learning, and the most misdiagnosed. It's almost never random — there's a specific, findable cause, and finding it is what we do all day.
A fixed, flat price per package. Not hourly, no meter running. The only other flat-rate SCORM repair specialist we've found charges noticeably more; agencies quote it as open-ended hourly work and take two weeks to reproduce the bug. Fixing five or more? The multi-package rate brings the per-package cost down.
Fix it yourself first, if you can
The 7 real reasons SCORM stops tracking
These cover well over 90% of the broken packages that cross our desk — and every one is diagnosable with a zip utility, a text editor, and a free SCORM Cloud trial. Or drop your .zip into our free SCORM Package Checker — it flags the package-level faults below in seconds, right in your browser, with nothing uploaded. Full depth is in our troubleshooting guide.
1. SCORM version mismatch
1.2 content looks for a JS object named API; 2004 looks for API_1484_11. Launch a package as the wrong spec and the handshake never happens — nothing records, not even an attempt start. Check: unzip, open imsmanifest.xml, read <schemaversion>, and compare it to what the LMS imported.
2. lesson_status vs completion_status
2004 split status into completion_status and success_status. If the course reports passed but the LMS completion rule watches for completed, the learner finishes and stays incomplete forever — neither side malfunctioning, just different dialects. Check: the authoring tool's "report status as" setting against the LMS rule.
3. Mastery-score overrides
A leftover adlcp:masteryscore makes many players (Moodle's 1.2 among them) recompute passed/failed from the raw score. A no-quiz policy course with masteryscore="80" scores 0, and the LMS flips the learner to failed. Fix: delete the masteryscore line from the manifest, or disable the override.
4. suspend_data overflow
SCORM 1.2 caps suspend_data at 4,096 characters — a limit from 2001. A modern 60-slide course blows past it; strict LMSs reject the write, permissive ones truncate, and the final status write is often lost too. Looks intermittent, isn't. Fix: republish as 2004 (64,000-char limit) or compress suspend data.
5. API discovery fails in iframes
The SCO finds the LMS API by walking the window.parent chain. Anything cross-origin in that chain — a CDN, a portal iframe, a proxy rewriting one hostname — and the browser blocks the walk. Tracks in SCORM Cloud, silent in your environment. Fix: serve content same-origin, or launch in the LMS's own player window.
6. LMS grading misconfiguration
Sometimes the package is innocent. A Moodle SCORM activity's Grading method plus completion conditions can demand data the package never sends — "require minimum score" on a status-only course means nobody ever completes it. Fix: set grading to Learning objects and build completion rules on status, not score.
7. A broken imsmanifest
The unglamorous stuff: imsmanifest.xml zipped inside a subfolder (Moodle rejects the upload); a resource marked scormtype="asset" instead of "sco" (launches with no tracking wired up); a launch href pointing at a renamed file. Fix: two minutes in a text editor finds all of these — or our free SCORM Package Checker flags every one in seconds, since reading XML by hand is tedious.
The 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. And if one LMS-wide setting is breaking ten packages, that's one repair, not ten. Broke right after a platform move? The migration is the likelier suspect.
How the flat rate works
Diagnose, repair, verify — with logs, not vibes
1. Diagnose
We upload your package to SCORM Cloud — the industry's reference implementation — with full debug logging, then run it in your LMS with a test login 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.
2. Repair
Depending on the cause: we edit the manifest 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 export settings, we document it so your next twenty exports come out right too.
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 | Effort & engagement | Turnaround |
|---|---|---|
| Free tracking diagnosis | Free | 1 business day from receiving files |
| SCORM repair, single package | Fixed, flat per-package price | 2–3 business days |
| SCORM repair, 5-pack | Multi-package rate, lower 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 get
SCORM repair FAQs
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.
Start here
Get a free SCORM diagnosis
Tell us what's happening with your tracking. An engineer replies within one business day — a fixed, flat per-package price if we fix it.