Moodle Completion Tracking: A Practical Setup and Audit Guide

Moodle completion tracking is reliable when each completion rule represents observable evidence, the gradebook and scheduled tasks are healthy, and administrators test the whole journey before enrolments begin. It becomes unreliable when teams treat a page view as proof of learning, change rules after launch or build reports without agreeing what “complete” means.

The short answer is: define the evidence first, configure activity completion second, combine only essential criteria at course level, and audit with test learners before using the data for decisions. Completion is a state recorded by Moodle; it is not automatically evidence of attention, competence or compliance.

What Moodle Is Actually Tracking

Moodle separates activity completion from course completion. Activity completion records whether a learner has met the rule for an individual resource or activity. Course completion evaluates a broader set of criteria and records whether the course as a whole is complete.

That distinction matters. A course can contain ten tracked activities while requiring only five of them for course completion. Conversely, every visible activity might show as complete while the course remains incomplete because a required grade, date, other course or manual approval criterion has not been satisfied.

Moodle's official activity completion documentation and course completion documentation, reviewed on 26 August 2026, describe the available settings. Exact navigation labels can vary slightly with the Moodle version, theme and enabled features, so administrators should validate the workflow on their own supported release.

Completion Is Not the Same as Restrict Access

Completion records a state. Restrict access decides whether a learner may see or enter something. The two features often work together—for example, a scenario may open after a prerequisite quiz is passed—but they solve different problems.

Keep the distinction explicit in the course specification. Otherwise a harmless reporting change can unexpectedly alter the learner's route, or an access rule can be mistaken for evidence that the prerequisite was meaningfully completed.

Start With an Evidence Map

Before opening Moodle settings, write one line for every item the organisation intends to report:

This exercise exposes weak proxies. “Viewed” can be appropriate for acknowledging a short reference page, but it does not show that someone read or understood it. A quiz attempt is not the same as a pass. A manual tick may be valid for observed practice, provided the authorised role, evidence source and correction process are documented.

Swift Learn's rule is simple: use the least complicated signal that still supports the claim you need to make. Extra conditions create more failure points and learner confusion without necessarily creating better evidence.

Configure Completion in the Right Order

1. Enable and Standardise the Course Setting

Confirm completion tracking is enabled at site level, then enable it in the course settings. Decide whether activity conditions should be shown on the course page and keep that presentation consistent across the programme.

For repeated delivery, configure the approved completion rules in the master course before creating cohorts or copies. A template is useful only when its settings are governed; copying an inconsistent course multiplies the inconsistency.

2. Choose Activity Rules That Match the Claim

Moodle activities may support manual completion, viewing, receiving a grade, passing a grade or module-specific conditions. The official Moodle 5.1 Activity completion API confirms that supported rules depend on the activity: modules can declare view tracking, grade-based completion and their own custom conditions.

Use these practical defaults:

• Use view for low-stakes resources where opening the item is the intended action.
• Use receive a grade only when any recorded grade is sufficient.
• Use passing grade when achievement matters, and verify the pass threshold in the gradebook.
• Use activity-specific rules, such as submitting an assignment or contributing to a forum, when they represent the intended behaviour.
• Use manual completion for learner acknowledgement or governed human judgement, not as a convenient substitute for missing automation.

Do not activate every available condition. If an activity requires both a view and a grade, test whether the activity reliably records both during the normal learner journey. Imported packages, embedded content and unusual navigation can make “viewed” behave differently from what a course designer assumes.

3. Build Course Completion From Mandatory Evidence

At course level, include only the criteria necessary to support the final claim. Name the mandatory activities, decide whether criteria are combined using all or any logic, and document any grade, date, enrolment-duration, prior-course or manual approval requirements you use.

A common mistake is to add every course activity to the completion criteria because it feels thorough. That makes harmless optional content capable of blocking the whole record. Separate mandatory evidence from enrichment, reference material and alternative routes.

This is also a learning-design decision. Our guide to course completion and learner engagement explains why visible progress and purposeful sequencing work better than a long trail of administrative hurdles. For shorter structures, the same discipline supports microlearning course design.

4. Check Background Processing

Some completion changes appear immediately; course-level evaluation and connected actions may rely on scheduled processing. A learner can therefore satisfy the visible criteria before the final course state or downstream notification updates.

Administrators should confirm that cron runs at the intended frequency, scheduled tasks are not failing, the server clock and site timezone are correct, and queues are not accumulating. If completion appears “stuck” across many users, inspect platform processing before manually overriding records.

Test Before Learners Arrive

Use dedicated test accounts representing the roles and routes that matter. Administrator testing is insufficient because elevated permissions can bypass restrictions or expose controls that learners never see.

Run at least these scenarios:

1. A learner completes the standard route and reaches course completion.
2. A learner fails an assessment, retries and then passes.
3. A learner completes optional content but omits one mandatory item.
4. An assessor records and, where permitted, corrects a manual decision.
5. A learner is suspended, unenrolled or moved between cohorts.
6. A completion-dependent activity unlocks at the expected point.
7. Reports and exports show the same status, identity and timestamp.

Capture expected and actual results. Check the learner-facing indicators, the activity completion report, the course completion report and any external reporting feed. If certificates, reminders or integrations consume completion data, include them in the test rather than assuming the Moodle record is the end of the process.

Audit Completion Data Without Guessing

When a record looks wrong, diagnose it in layers.

Check the Definition

Confirm which criteria currently define completion and whether they are joined by all or any logic. Compare the live settings with the approved course specification. Look for rules changed after enrolment began.

Check the Underlying Evidence

For a grade condition, inspect the learner's attempt, gradebook value, passing threshold and aggregation. For a submission condition, confirm the submission state rather than relying on a course-page indicator. For a manual decision, identify who changed it, when and under what authority.

Check Processing and Scope

Review scheduled-task health, enrolment status, groups, role assignments, availability rules and relevant dates. Establish whether the problem affects one learner, one activity, one course or the whole site; that boundary usually points towards data, configuration or platform processing.

Use Overrides as Controlled Corrections

An authorised override can correct an exceptional record. It should not hide a systematic configuration failure. Record the reason, approver and supporting evidence, and fix the root cause before the next cohort.

Changing locked activity-completion rules after learners have generated data can recalculate or remove states depending on the change and workflow. Treat post-launch edits as controlled changes: export evidence, test on a safe copy, communicate the effect and keep an audit note.

Reporting That People Can Trust

Agree a small data dictionary for each report field: activity complete, course complete, passed, overdue, exempt and manually approved are not interchangeable. State the reporting timezone and the rule for late-arriving updates.

For compliance-sensitive delivery, retain enough context to interpret the result: learner identity, course and activity versions, completion criteria, assessment outcome, timestamp and authorised exceptions. Moodle can record useful evidence, but course governance determines whether that evidence remains defensible.

Completion data should also improve design. High drop-off before one activity may indicate an unclear instruction, inaccessible resource, broken condition or excessive effort—not a motivation problem. Pair the report with learner-path testing and support data. Use Moodle gamification only where it reinforces meaningful progress rather than rewarding superficial clicks.

A Sustainable Administrator Checklist

Before launch:

• define every reported claim and its evidence;
• configure rules in the approved master course;
• verify pass grades, aggregation and alternative routes;
• test with real learner and assessor roles;
• confirm cron, scheduled tasks and integrations are healthy; and
• approve the reports, exports and correction procedure.

During delivery:

• monitor task failures and unusual completion backlogs;
• sample records against underlying submissions or grades;
• log authorised overrides and learner-impacting changes; and
• investigate patterns rather than repairing records one by one.

Before the next cohort:

• review exceptions and support cases;
• remove conditions that add friction without evidence;
• regression-test course copies and integrations; and
• archive the completion definition with the course version.

The Swift Learn Verdict

Reliable completion tracking is an architecture, not a checkbox. The architecture connects a defensible evidence definition, restrained activity rules, clear course criteria, healthy background processing and reports that preserve context.

If completion matters only for learner orientation, keep it light and visible. If it triggers certification, compliance action, access or management reporting, govern it like any other business-critical data flow. The cost of a careful setup is modest; the cost of discovering unreliable evidence during an audit is not.

For organisations without time to test upgrades, scheduled tasks, course templates and reporting together, a defined managed Moodle support boundary can make ownership explicit.

Need a Moodle Completion and Reporting Review?

Bring us one representative course, the reports you rely on and the exceptions your team currently repairs by hand. Swift Learn will trace the evidence flow, identify fragile rules and give you a prioritised configuration and testing plan.