When Open edX timed exams and CCX fit your course program
Timed exams and Custom Courses (CCX) in Open edX let a course team run assessments under a clock or give a cohort its own separate copy of a course on the same self-hosted platform. A timed exam limits how long a learner can work on a graded assessment once started. A CCX is a derivative course that shares the parent course content but keeps its own enrollments, schedule, instructor roles and grades. Whether these two features are enough is a decision for the course program owner, the instructional design lead and the platform owner together, because the answer depends on how strict the assessment must be and how many cohorts run in parallel.
Start by writing down what the course program actually needs. If the requirement is a fixed time window for a quiz or a final assessment, and the institution is comfortable with honor-based conditions, timed exams may cover it. If the requirement is identity verification, locked browsers, webcam monitoring, or evidence that an exam was taken without outside help, the built-in timer does not provide that control. Those needs point toward a dedicated proctoring tool, and the team should decide early whether it will integrate one with the Open edX platform or accept a gap for certain courses.
Next, confirm the exact feature flag names and how they behave in the Open edX release you run. The Open edX documentation for that named release is the authority here, because flag names, defaults and related Studio and LMS settings can differ between releases. No release-specific flag details are supplied for this page, so the platform engineer should check the documentation for the version in use and test each flag on a staging instance before anyone builds a course around it. The same check should cover whether CCX must be enabled for the instance, and which course roles can create and manage CCX copies.
CCX also has operational consequences that course teams often underestimate. Each CCX is a separate set of enrollments and grades, so a program with many cohorts multiplies the instructor and support work. Decide who creates CCX courses, who sets their schedules and deadlines, and who answers learner questions when a cohort copy diverges from the parent course. Ask the platform operator to confirm how CCX data appears in reports, in certificates and in any analytics pipeline the institution already runs, since those outputs may need separate handling.
Finally, plan for the cases where these features will not fit. If the program requires strict exam security, reliable accommodations for timing, or an audit trail that a regulator or accreditor will examine, document the gap and the compensating controls before rollout. A useful first step is a short written scope listing each course, the assessment type, the security requirement and the owner who signs off. That list shows whether timed exams and CCX cover the program, and where a dedicated proctoring tool or a different assessment design is needed.
Timed exams, CCX or a dedicated proctoring tool: which option fits
This table compares native timed exams, Custom Courses (CCX) and a dedicated proctoring service connected through LTI or a similar integration. Read each row across the three paths to see what problem each one solves, who changes its settings, how learner identity and grade reporting are affected, and what you must confirm before choosing. The main takeaway is that native timed exams and CCX control timing and cohorts inside the platform, while identity checks and proctoring evidence usually come from a separate tool.
| Question | Native timed exams | Custom Courses (CCX) | Dedicated proctoring service via LTI |
|---|---|---|---|
| Need it addresses | Time-limited graded assessments inside one course run for all enrolled learners | Separate copies of a course for a cohort, with its own dates, enrollments and staff | Identity verification, monitoring or review of learners during an assessment |
| Configuration owner | Platform operator enables the feature; course team sets time limits and exam settings in Studio | Platform operator enables CCX; course team or staff creates and manages each cohort copy | Platform operator registers the tool and keys; course team places the tool in the course outline |
| Identity implications | Learners sign in through the platform's existing authentication; no extra identity check is built in | Cohort members are enrolled in the CCX copy; identity follows the same platform accounts | Learner identity is checked by the vendor; you must confirm what data is shared and how it returns |
| Reporting implications | Timed attempts and scores appear in the instructor dashboard and gradebook of the course run | Grades and progress are reported per CCX copy, so cross-cohort reports need separate handling | Proctoring results return as grades or attempt records; confirm which fields reach the LMS |
| Main gap to confirm | Confirm the exact flags and exam settings for your release, since they change between named releases | Confirm how CCX copies are maintained, exported and reported in your installation before rollout | Confirm vendor capabilities, LTI version support, data residency and retention terms in writing |
How course teams use timed exams and CCX in Studio and the LMS
A timed exam in Open edX is set up in one place and experienced in another. Studio, the CMS service, is where the course team builds the exam structure and its settings. The LMS, the learner-facing service, is where the timer runs, answers are submitted and grades are shown. Plan and test both sides before any learner starts. A setting that looks correct in Studio can still behave differently for a learner in the LMS, so the review should follow an attempt from start to finish. Confirm the exact authoring steps for your release in the Open edX release notes and platform documentation, because the location of some settings has changed between releases.
In Studio, the course team decides which content belongs in the exam, whether it is graded, how long learners have, and when it is available. These decisions shape the learner's experience and the records you keep. Settings changed after learners have started an attempt may not apply the way authors expect, so agree on a freeze point before the exam opens. Custom Courses (CCX) add a second layer. A CCX is a separate copy of a master course that has its own enrollments, dates and staff, which lets a coach run a cohort with different schedules. Confirm in the documentation for your release where CCX copies are created, how they inherit content from the master course, and which changes flow down to them.
Learners see the exam through the LMS. They should find the timer, the navigation between questions, the submission step and the status of the attempt. The platform's timed exam experience does not include identity verification, live monitoring or browser lockdown. If your assessment policy requires any of these, plan a dedicated proctoring tool and test how it connects to the course before launch. Also decide what learners see after submission, including whether scores appear immediately, and check that the learner view matches the policy you have agreed with academic or training leads. Run a learner-view walkthrough on each browser and device type your learners use.
Instructors and CCX coaches monitor progress and manage exceptions through the instructor dashboard in the LMS. They use it to review learner progress and grades, and to handle requests such as extensions and resets. The instructor dashboard was redesigned in Verawood, so menus, labels and the location of some tools differ from earlier releases. Train staff on the release you deploy and keep a short written procedure for common exception requests. Confirm the current dashboard features and permissions in the Verawood release notes and the platform documentation, and test each exception path in a staging CCX before the exam window opens.
Enabling timed exams and CCX on a self-hosted Open edX platform
This sequence takes a self-hosted Open edX platform from a confirmed release to a tested staging setup in which timed exams and CCX copies behave as expected for each role. Each step depends on the release and settings fixed before it, so production should follow only after the staging checks pass.
Confirm the Open edX release in use
Confirm which Open edX release the platform will run before any configuration. Verawood is the current named release, published on 30 July 2026, and Open edX states that only the latest named release is supported. Note that Willow is listed for December 2026, and decide whether the project ships on Verawood or plans an upgrade. Record the chosen release in the project plan, because the setting names and screens in later steps come from that release's documentation. Done when the release, its support status and the platform owner's sign-off are written down.
Deploy or update the platform with Tutor
Deploy the chosen release with Tutor on infrastructure you control, such as your cloud account, data center or air-gapped network. Tutor is the official Docker-based Open edX distribution and supports Kubernetes. The edx-platform maintainers recommend it over a bare-metal install, which they describe as complex with limited community support. Your team or DeployOpen performs the installation. Confirm that Studio and the LMS load over HTTPS, that an administrator can sign in, and that the running version matches the decision from the first step.
Enable the required settings in staging
Look up the timed exam and CCX settings for your release in the edx-platform repository and the Tutor documentation. Set them through Tutor configuration or a plugin so the change survives redeploys. If your team builds from source, the repository lists development prerequisites, including Python 3.12, Node.js, MySQL 8.0, MongoDB 7.x and Memcached. Restart the services and confirm that each setting took effect. Done when a staging instance shows the timed exam and CCX options in Studio and the instructor dashboard, and the configuration change is stored in version control.
Configure a test course with a timed exam
In Studio, build a small test course with one timed exam subsection, set its time limit and publish it. Enroll a test learner account and start an attempt. Check that the exam stops accepting answers when the limit is reached. Also record what happens when the learner closes the browser or loses the connection, because that behavior determines what course teams can rely on. Done when the expiry behavior is observed on the staging instance, the grading output matches the expected score, and both results are saved to the test log.
Create a CCX copy of the test course
Create a CCX from the test course using the instructor interface for your chosen release. The Verawood release redesigned the instructor dashboard, so confirm the exact path in that release's documentation. Enroll two test learners in the CCX and assign a coach who manages only that copy. Check three things: CCX learners see only the CCX copy, learners enrolled only in the main course do not see CCX content, and a change made in the CCX does not alter the parent course. Done when all three checks pass and the results are saved with the test log.
Verify learner, staff and instructor access
Test each role on the staging instance: a learner, course staff, an instructor, a CCX coach and a platform administrator. For each role, confirm what it can see in the course, the exam and the instructor dashboard, and what it is blocked from doing. Compare the results with the access model your organization approved. Note in the record that timed exams and CCX do not provide dedicated proctoring features, so identity checks or monitoring for high-stakes exams must be assessed separately. Done when expected and actual access match for every role in a signed test record.
Security and operational considerations for exams and CCX
Timed exams and Custom Courses (CCX) add instructor-facing data, roles and records to a shared Open edX platform. The cards below cover the decisions and checks that determine who can see what, how assessment data is kept, and how the platform stays recoverable and observable once exams run in production.
Who can create CCX courses
Creating a CCX copies a master course into a per-coordinator course with its own enrollments, staff and grading. Decide which staff roles may create CCXs and who may grant them, because a CCX holder can manage enrollment in that copy. Verify by creating a CCX with a test coordinator account, confirming that account cannot reach courses it was not assigned, and checking that the change is recorded in the platform audit trail you have configured.
Who can see exam results
Exam scores are visible to course staff, to the CCX coordinator for their own copy, and to each learner for their own attempts. Confirm which instructor dashboard and grade export roles reach timed exam data in your release, and whether a CCX coordinator can see results beyond their enrolled learners. Test with a learner, a course staff account and a CCX coordinator, and compare what each can export.
How third-party sign-in affects enrollment
When learners authenticate through SAML 2.0, Shibboleth, an OAuth2 provider or LTI, identity attributes decide whether they are created, matched to an existing account and enrolled. A CCX enrollment list built on email addresses can break if the identity provider releases different or missing attributes. Confirm which attribute maps to the account, run a sign-in from each provider with a test user, and check that the learner lands in the intended CCX.
Assessment record retention and access
Timed exam attempts, scores and timestamps are personal data about learners and need a defined retention period, deletion path and export process. Agree with your legal and records owners which fields are kept, how long, and who may export them. Verify by running a retention test on a staging course, deleting a test learner, and confirming which records remain in the database, exports and logs.
Database and cache for multi-node deployments
Open edX relies on MySQL for course and enrollment data and MongoDB for course content, and multi-node deployments need a shared Django cache such as Redis or Memcached so every LMS and Studio node sees the same session and timed exam state. Confirm the versions your release requires and that cache nodes are shared, not local. Verify by taking one LMS node out of rotation during a test attempt and checking that the learner's timer and answers survive.
Backups that cover exam state
A backup of the relational database alone may miss MongoDB course content, file storage and cache state that an in-progress exam depends on. Define a backup set that restores course content, enrollments and attempts together, and set a recovery point that matches your exam calendar. Verify by restoring the full set into a separate environment and comparing one CCX's enrollments and recent attempts with production.
Logging exam and CCX activity
Platform logs, tracking logs and grade change records are the evidence trail for disputes and incident reviews. Decide which events are forwarded to central logging, how long they are kept, and who can search them, since logs can also contain learner identifiers. Verify by changing a CCX enrollment and a grade in a test course, then confirming both events appear in the central log store with the actor and timestamp.
What does it cost and take to set up timed exams and CCX?
What drives the cost of setting up timed exams and CCX in Open edX?
Scope size, identity integration and the number of environments drive most of the cost, so write each one down before asking for a quote. The main drivers are: the number of courses that will use timed exams or CCX, the identity integration each course needs (how learners and CCX coaches are authenticated and enrolled), the number of environments such as development, staging and production, the depth of testing (a smoke check of one exam or a full matrix across roles and browsers), and how current the release is when work starts. Each driver shifts cost between partner engineering time, your identity administrator's time and your course team's time for test courses. Ask for a quote that lists each driver separately, so you can see which decisions move the total.
Is setup a one-time cost or does it recur after launch?
Initial configuration, test course construction and sign-off are one-time work, while regression testing and maintenance recur. Recurring items include testing after each platform upgrade, maintaining feature flags and any plugins, updating exam policy when rules change, and ongoing support if you hold a retainer. Upgrades are the largest recurring item. Open edX states that the latest named release is the only supported release. Verawood is the current named release, and Willow is listed for December 2026. Each release can change how timed exams and CCX behave, so plan the recurring test cycle from the start. Ask the partner to state in writing which upgrade work sits inside the fixed scope and which is quoted separately.
What do we need to provide before a partner can start the work?
Name one owner per area before work starts, because most delays come from open decisions. You will need: a product owner who signs off exam policy, covering time limits, attempt rules, what happens when a connection drops and how accommodations are handled; a course operations lead who provides test courses that cover each exam type; an identity administrator who can grant time for SSO and enrollment testing; and a platform owner who approves feature flag changes and access to each environment. Add a security or compliance reviewer if exam records are in scope. Confirm these people's availability for review windows, and record their names and dates in the written scope.
Can our course team enable timed exams and CCX without outside help?
A course team can handle basic authoring, but enabling the features and checking them across environments usually needs a platform engineer. A platform administrator must turn on the relevant feature flags and confirm they match in every environment. Course authors can then build timed sections and, where CCX is enabled, set up a custom course for a cohort. Check that the exact steps, roles and limits match the release you run by reading the feature flag documentation for that release. Work that touches identity, grade export or production data belongs with the platform team. Ask the partner which parts it will hand over through training and which it keeps.
How long does timed exam and CCX setup usually take?
Duration depends on scope, so ask for milestones tied to scope rather than a generic timeline. The items that extend the work include the number of course types, identity integration that must be built rather than reused, the number of environments, how many sign-off cycles your policy requires and how quickly your owners answer questions. A pilot with one exam type and working identity is a much smaller project than a rollout across several courses and sites. Ask for milestones that show your dependencies, such as the dates when test courses and sign-offs are due. Any date in a quote should list its assumptions and state what happens if your side is late.
Does Open edX timed exam setup replace a dedicated proctoring service?
No. Open edX timed exams provide time limits and exam structure within a course. They do not include live or recorded proctoring, identity verification of the test taker during the exam, or the reporting that proctoring vendors provide. If you need those controls, decide before scoping whether a third-party proctoring tool will be integrated, who holds its contract and who maintains the integration after upgrades. Confirm the exact capabilities of your release against the Open edX documentation and the partner's written scope. State proctoring explicitly as in scope or out of scope, so the quote does not assume a control that no one will test.
What should a written scope and quote for CCX include?
A written scope should list each course and exam type, each feature flag and role change, the identity integration and its owner, the environments covered, the test plan and acceptance criteria, sign-off dates and the handover format. Include exclusions such as proctoring, custom grading and data migration. Ask which release is targeted, what regression testing is included and whether future upgrades fall under a separate retainer. Request cost components separately: partner labor, licenses for any third-party tool and infrastructure changes in your environment. Require a list of what your side provides, with dates. Quotes that omit these items cannot be compared with each other.
Which checks confirm that timed exams and CCX work before launch?
Test the failure paths, not only the normal path. Confirm that the timer, submission and attempt rules behave as your written policy states, including a page refresh and a dropped connection during an attempt. For CCX, check that enrollment and grades stay inside each custom course, that coach permissions show only that course's learners and that exported grades match the gradebook. Run the same checks in staging and production using the same flags and configuration version, so differences show up early. Record results against the acceptance criteria in the scope, and keep the test course set so you can run it again after each upgrade.
What timed exams do not provide compared with proctoring tools
Native timed exams and Custom Courses (CCX) control the clock and the course structure. They set time limits, sequence content, and keep a learner's attempt within a defined window. They do not, by themselves, verify who is taking the exam, watch the learner during the attempt, or check the device, browser or room. A proctoring service adds those controls. Before a course team relies on a timed exam for anything that carries weight, it should confirm in the documentation for the Open edX release it runs exactly which behaviors are native and which would need an external service. Treat the native feature as a timer and a structure, not as an assessment security control.
The decision to add an external proctoring integration should be made course by course, not for the whole platform. Start with the stakes of the assessment, the expectations of the accrediting body or regulator, and whether the institution must be able to show who sat the exam. Then consider fraud risk, cohort size, and accessibility accommodations, since some learners will need alternative arrangements that a proctoring tool must support. A short practice quiz and a credential that leads to licensure carry different risk. The outcome of this review determines whether the integration is worth its cost and effort at all, so record the reasoning alongside the course design.
If the review points to proctoring, put specific questions to each vendor and ask for written answers. Ask how identity is verified and what the learner must provide. Ask whether monitoring is live, recorded, or automated, where recordings are stored, how long they are kept, and who can access them. Ask what environment checks run, how the vendor handles accommodations and exceptions, and how it integrates with a self-hosted Open edX site, including which integration method it supports and on which release. Every capability claim, including those in marketing material, must be confirmed with the vendor and tested in a pilot course before a commitment is made.
Responsibilities need to be divided before the build starts. DeployOpen can prepare and integrate the Open edX side: course configuration, the launch and grade-return path, test cases, and operating documentation. The proctoring vendor operates its own service and its own data handling. The institution owns the assessment policy, learner notices, consent and data protection decisions. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors perform that role. When requesting quotes from vendors and from DeployOpen, ask which costs are one-time and which recur, such as per-learner or per-exam fees and hosting.
Limits to confirm in your environment before rollout
Timed exams and Custom Courses depend on the Open edX release, the Tutor version and the rest of your platform, so a demo can differ from your build. The cards below list what to verify, and each names who should confirm it: vendor documentation, your platform team or your compliance owner. Settle these items before course teams are given a launch date.
Release-specific timed exam behavior
Timed exam and CCX behavior can change between named Open edX releases, and the latest named release is the only one the project supports. Read the release notes for the version you plan to run, including Verawood, published on 30 July 2026. Record how timers, submission cut-offs and attempt handling behave, then reproduce each behavior in a test course. Who confirms: vendor documentation, checked by the platform team.
Feature availability in your Tutor version
Which timed exam and CCX options appear depends on the release you install and the Tutor version that builds it, so a feature in one release note may be absent from your image. Pin the Tutor version, list the settings and feature flags your course teams need, and confirm each one in a staging build before the image is frozen. Who confirms: the platform team, using Tutor documentation and a staging instance.
Grading and reporting integration
Timed exam scores have to reach the gradebook, certificates and any downstream reporting your organization relies on. Check how exam results appear in the instructor gradebook, how partial submissions and late attempts are recorded, and whether exports match what your registrar or data team expects. Who confirms: the platform team with the data owner, using a test course with scored submissions.
Accessibility of timed assessments
Time limits can disadvantage learners who need extra time or who use assistive technology, so timed assessments need a documented accommodation path. Test keyboard navigation, screen reader announcements of remaining time and the presentation of timer warnings. Decide who grants extended time and how each grant is recorded. Who confirms: the compliance owner with accessibility staff, using testing with the assistive technology your learners use.
Exam traffic and concurrency
Timed exams concentrate many learners into the same window, which loads the LMS, database and cache at the same time. Ask the platform team to size LMS workers, database connections and the shared cache backend for your expected peak. Multi-node deployments need a shared Django cache backend such as Redis or Memcached. Run a load test that starts sessions within a narrow window. Who confirms: the platform team, through load testing against staging.
Willow authorization and course team access
Role-based authorization for Studio is planned to become the default in Willow, which is listed for December 2026. Course teams that build or edit timed exams may see different permissions after that change, so confirm which roles hold exam and CCX authoring rights today and how they map under the new model. Who confirms: vendor documentation for Willow and the platform team, with course leads signing off the role matrix.
How DeployOpen scopes and delivers timed exam and CCX work
DeployOpen plans, implements, documents and supports self-hosted Open edX inside your own infrastructure, so timed exam and Custom Courses (CCX) settings are decided, tested and handed over as part of a written scope. The work starts with which feature flags your course teams need and how they will use them, and it ends with a team that can run the configuration after the project closes.
How we scope
- Written scope lists which exam and CCX features are enabled, and which course teams and roles will use them.
- Scope records the Open edX release and Tutor version the configuration targets, so the feature flags match that release.
- Scope states what is out of scope, including dedicated proctoring tools that Open edX does not provide on its own.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work begins.
How we build
- Feature flags for timed exams and CCX are set through Tutor configuration so the settings are version-controlled and repeatable.
- Test courses cover timed exam start, submission, and time-limit behavior, along with CCX enrollment and instructor access.
- Course team workflows are checked against the agreed scope, including how exams are authored and how CCX copies are created.
- Known gaps against dedicated proctoring tools are recorded as limits in the design, not left for course teams to discover.
How we hand over
- Handover documents the enabled flags, the Tutor configuration files, and the reasons each setting was chosen.
- Course authors receive a short runbook covering creating timed exams, assigning CCX courses, and reporting problems.
- Operators receive upgrade notes describing which flags and behaviors to recheck when Open edX changes releases.
- Verification results from the test courses are delivered with the documentation so your team can repeat the checks.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover rechecking exam and CCX behavior each time your Open edX release or Tutor version changes.
- Ask in the quote which support hours, response expectations and upgrade checks are included in the retainer.
- Confirm with DeployOpen which exam and CCX behaviors your proctoring policy requires before the scope is signed.
