When the connection drops, StudyDrome Exam Manager retains each answer in the browser and replays it upon reconnection. Answers persist locally for 24 hours. The clock does not stop. The server owns it, and the client re-checks every 20 seconds while offline. The attempt survives the outage. The session has to be rebuilt.
That is the short answer. The longer one matters because "we lost the internet" is not a single failure. It is three, and they fail differently.
What actually breaks when the connection drops?
Three things are at risk, and they are independent:
- The answers already given. These live in the browser first and the server second.
- The clock. It never lived in the browser at all.
- The session. This is the part that genuinely stops.
Most support calls confuse the first with the third. A candidate says "I lost everything". Usually they lost the page, not the work. Knowing which is which turns a panic into a two-minute fix.
The cost of getting this wrong is not technical. It is an appeal. A candidate who drops offline for eleven minutes and finishes late will contest the result. Your defense is a record of what the system did, not a promise about what it usually does.
Where do the answers go while the connection is down?
Two places, in this order. The browser holds the answer, then the server confirms it.
Each answer is saved on its own schedule. The interval is not global. It depends on the question type, because typing and clicking are different problems:
Question type | When the answer is sent |
|---|---|
Multiple choice and other selections | Immediately |
Fill in the blank | 1 second after typing stops |
Short answer | 3 seconds after typing stops |
Essay | 3 seconds after typing stops, plus every 30 seconds |
Each question has its own pipeline. Typing in one item never cancels another item's save.
Every pending answer is also written to browser storage, keyed to that candidate's exam. Entries are kept for 24 hours and then discarded. If the tab crashes or the candidate refreshes during an outage, the answers are read back and sent again. They see a message saying how many were recovered.
An answer is only cleared as saved on a real success. A failed call leaves it pending on purpose, so it can be retried.
When the network returns, the system spots the moment it changes from down to up. Everything still pending is flushed then. The candidate does not have to do anything.
While that is unresolved, the exam screen shows a count of unsaved answers and a Retry sync button. That count is deliberately narrow. It counts answers whose save has definitely failed. It does not count answers still in flight. So the number does not flicker every time a request is slow.
Storage can fail too. Private browsing and a full disk both break it. Those failures are caught and ignored rather than passed to the candidate. Losing local backup is bad. Ending someone's exam because their disk is full is worse.
What happens to the exam timer?
It keeps running. This is a design decision, not an oversight, and it is worth stating to candidates before exam day.
The countdown on screen is a display. The server holds the real remaining time. The client corrects itself against the server on two channels:
- A live connection sends the authoritative remaining seconds about every 30 seconds.
- A separate status request runs in parallel. It fires every 60 seconds while that connection is up, and every 20 seconds while it is down.
The second one speeds up exactly when the first one fails. That is the point of having both.
Small gaps are ignored. A difference of 2 seconds or less is treated as ordinary clock variance. Larger gaps are corrected. A gap of over 30 seconds is also logged because it usually indicates something worth investigating.
There is one more detail with practical value. The faster check, the one that runs while disconnected, keeps running even when the tab is in the background. The slower check pauses when the tab is hidden. So a candidate who switches away during an outage still returns to the correct clock.
A proctor gives lost time back by hand. The adjustment travels on the same channel as the countdown. The candidate sees a notice that their time has changed.
Can the candidate get back into the exam?
Usually yes, and the checks run in a fixed order: holds, then device, then network, then time.
Device. An exam can be set to allow resuming only from the browser that started it. The check runs on resume, not at the start. Starting the exam sets the binding. It never tests it. If the check fails, the candidate is told to return to their original browser.
That restriction is optional and can be defeated, and it should be described honestly. It identifies a browser profile. It does not identify a person or a machine. If fingerprinting is blocked, it fails open rather than locking someone out of their exam.
This matters on exam day because hardware dies. A proctor can clear the stored device for one candidate, several, or everyone on an exam. The next resume binds to whatever machine they are now using. A candidate whose laptop fails can switch to a spare without anyone touching the database.
Network. If the exam is limited to certain addresses, that is re-checked on resume. A candidate who reconnects through a phone hotspot may be refused. Decide before the exam whether that is what you want.
How does the exam end if the candidate never comes back?
The system tries to finish cleanly first. On expiry, it flushes every pending answer, then submits. If the submit itself fails, it is queued and replayed when the network returns. Answers go first, then the submission.
Expiry can be triggered by three different sources, so it is guarded to run once. A candidate cannot be submitted twice because two channels noticed the same deadline.
When the attempt is finally accounted for, it lands in one of eight categories:
- in progress
- finished by student
- time expired
- test window expired
- terminated for violations
- finished by administrator
- abandoned or session timeout
- unknown
The seventh matters more than it looks. Abandoned or session timeout is its own category, separate from terminated for violations. A candidate whose connection died is not filed alongside a candidate who was submitted for breaking the rules. That distinction is the one an appeals panel needs, and it is the reason to record the reason at all.
There is a second use for it. Closing an abandoned attempt frees the seat it was holding. That matters when an exam caps the number of people who can sit it at once. A ghost attempt should not block a real candidate.
Afterward, each attempt carries its sessions. A session count above one is the signal that someone dropped out and came back. Each session records its address, its browser, and when it started. Pair that with the conduct record we use in place of recording candidates. Together they reconstruct an exam-day outage, with no video of anyone's home.
What this cannot do
Six limits. Each is a real boundary, not a caveat.
An exam cannot be started offline. Local storage protects answers given during an online session. Loading the exam still needs the server. There is no offline app.
A queued submission does not survive a page reload. Pending answers are written to storage. The queued finish is held in memory only. If a candidate reloads mid-outage, the answers come back, and the submission does not. It is retried when the network returns, provided the tab stayed open.
An exam cannot be paused. Not for a fire alarm, not for an outage. The mechanism for lost time is a time adjustment made by a proctor.
Nobody sees the drop instantly. A proctor learns about a disconnection at the next refresh, at best 30 seconds later. They learn it by reading session data. Monitoring is near real-time, with an update as fast as 30 seconds. Push to the candidate is genuinely instant. Push to the proctor is not. No honest vendor should describe the two the same way.
Device binding is not identity. It is a browser profile that fails open.
The review page is off by default. If you want candidates to see a summary before submitting, turn it on when you build the exam. What that summary should contain is part of designing the exam interface.
A checklist for exam day
When | Do this |
|---|---|
Before | Publish the connection and browser requirements and make candidates confirm them. Ours are in the system requirements. |
Before | Decide whether resuming on a new device or a new network is allowed, and inform the invigilators of your decision. |
Before | Tell candidates the clock keeps running during an outage. Surprise is what turns an incident into a complaint. |
Before | Name the person who can grant extra time, and first agree on what evidence they need. |
During | Treat an unsaved count as a live alert, not a display. Reconnecting clears it. |
During | Reset the device binding rather than moving a candidate to a new account. |
After | Pull the conduct record for every attempt that did not finish normally. |
After | Check the finish reason before contacting a candidate. Abandoned is not a violation. |
Frequently asked questions
What happens if you lose internet during an online exam?
The exam does not end. Answers already given are stored in the browser and resent when the connection is restored. The countdown keeps running, because the server owns it, not the browser. When the candidate reconnects, the attempt resumes where it stopped. Only the live session is genuinely lost and is rebuilt upon return.
Are answers lost when the connection drops?
No, provided the tab stays open or is reloaded within 24 hours. Each answer is written to browser storage and sent to the server. Failed saves stay pending instead of being discarded. When the network returns, all pending items are sent automatically. The exam screen shows a count of unsaved answers and a retry button until it clears.
Does the exam timer keep running while a candidate is offline?
Yes. The countdown is a display; the server holds the real remaining time. While the live connection is down, the client rechecks every 20 seconds instead of every 60 seconds. Differences of 2 seconds or less are ignored as normal clock variance, and larger ones are corrected. Lost time is returned by a proctor as an explicit adjustment.
Can a candidate rejoin an exam from a different device or network?
Only if the exam allows it. An exam can restrict resuming to the browser that started it. That check runs on resume. Network restrictions are re-checked at the same point, so a hotspot may be refused. A proctor can clear the stored device. That lets a candidate move to a replacement machine.
Can an exam be paused for a technical failure?
No. There is no pause. The supported response is a time adjustment: a proctor adds minutes to the affected attempt, and the candidate sees a notice that their time changed. This is deliberate. A pause is hard to audit. An adjustment leaves a record of who granted it and how much they gave.
How does an exam office show a candidate was disconnected rather than cheating?
By the recorded finish reason and the session history. An attempt that ends due to disconnection is filed as abandoned or as a session timeout. That is a separate category from terminated for violations. Each attempt lists its sessions with the address, browser, and start time. A session count above one shows the candidate dropped and returned.
Where to go next
Reviewing a platform rather than fixing a policy? Ask vendors what happens to the clock during an outage, and ask them to name the interval. Vague answers here are the ones that produce appeals later. Our security overview covers how we handle exam data. Our comparison with ExamSoft examines the different approaches a desktop application takes to the same problem. Navigation, flagging, and what a candidate sees before they submit are separate decisions, made while the connection is fine. They are covered in what candidates need from an exam interface.