Twenty minutes into a forty-minute test, one laptop in the second row goes black.
What happens next is not really a technical question. The invigilator has to decide, in front of twenty-nine other students, whether that child has lost the paper, gets it back, or sits it again next week — and they have to decide now. Whatever the software does is only useful to the extent that somebody knew in advance what it was going to do.
So this is an account of the four interruptions that actually happen, what each one leaves behind, and the policy worth writing down before the next exam rather than during it.
Four interruptions, four different answers
These feel similar in the room and are not similar at all. The distinction that decides each one is whether a submission was ever triggered.
| What happened | Back into the paper? | Why |
|---|---|---|
| Power cut, dead battery, browser crash, closed lid | Yes | Nothing was submitted. The attempt is still open. |
| Connection dropped, then came back | Yes | Same — an unreachable server is not a submission. |
| Ended automatically after a second warning | No | A submission was triggered and recorded. |
| Time ran out | No | The paper submitted itself. |
The useful line to remember is the one in the first column: a crash is not an attempt. A student whose device died has not used up their paper, and the system should not treat an interruption as a submission. The common mistake in this category of software is locking the attempt the moment it opens, which converts every power cut in the building into a re-sit request.
The one-day detail worth knowing is that an open attempt does not stay open forever — the record of it being started clears itself after about twenty-four hours. In practice that is longer than any single sitting and shorter than a week, so it covers the real case (back in ten minutes) without leaving a paper reopenable the following Monday.
What survives a reload, and what does not
Getting back into the paper is the first question. The second is what is still in it. Here there is an asymmetry worth planning around, and it is not the one most people expect.
| Answer type | After a reload |
|---|---|
| Code | Restored |
| Written / long answer | Restored |
| Numeric | Restored |
| Multiple choice, single or multi-select | Lost |
Typed work is saved locally as it is typed, per question. Selections are read from the page at the moment of submission.
So a student who had written four paragraphs and a function gets all of it back. A student who had ticked thirty boxes gets none of them back and starts again.
The reasoning behind that split is defensible: a paragraph represents twenty minutes of thinking that cannot be reproduced quickly, while a selection is one click, and saving every keystroke of typed work is cheap insurance against exactly the scenario in this article. But the consequence is operational and nobody discovers it at a convenient moment:
Two further limits on the restore, both worth knowing before you rely on it:
- It is per device and per browser. Work saved on the lab desktop is not on the student's phone. Moving a child to a spare machine mid-exam gives them a blank paper even for typed answers.
- It needs the browser's own storage. A private or incognito window, or a device that clears storage on close, restores nothing. If your lab images wipe profiles between sessions, this protection is not there.
When the submission is the thing that fails
The interruption that causes the most distress is not the one in the middle of the paper. It is the one at the end, when a student presses submit and the connection is gone.
Two behaviours are worth asking about here, because they differ and the difference shows up in the room.
An automatic submission — time up, or a paper ended by a second warning — retries. It tries again a few seconds later, up to three times, because there is no student decision left to make and nobody to ask. If all three fail, the screen says so explicitly and tells the student to photograph it and inform the teacher. That instruction exists because the alternative is a child sitting in front of a spinner deciding whether to walk out.
A manual submission does not retry. It reports the failure and re-enables the button, which is the right behaviour: the student is still there, still has the paper, and pressing it again is both the obvious action and a safe one. A silent retry loop behind a button the student thinks has failed is how a paper gets submitted twice.
The practical instruction for an invigilator is small and specific: if a submit fails, do not close the tab. Everything typed is still in that browser, and the submission can be retried from it. Closing the tab is the one action that turns a recoverable problem into an argument.
What the teacher can see afterwards
A re-sit decision made a day later needs evidence, and three recorded facts carry most of it: when the student opened the paper, how long they had it open, and whether it ended by itself and for what reason.
That last one is what separates the cases that look identical in a mark list. A result of 12 out of 40 could be a student who struggled, or a student whose paper ended for them at the twenty-minute mark. Without a recorded reason those are the same row, and the difference between them is the difference between a grading conversation and a pastoral one.
There is one thing that no record can tell you, and it is worth being plain about it: the system knows the paper was reopened, not what the student was doing in between. A reopened attempt proves an interruption occurred, not that it was a power cut. That gap is closed by an adult in the room, which is the same conclusion as the question of what in-browser controls can enforce — and for the same reason. Because a reopened paper does not come back with a clock that knows what it has already been given, the invigilator should note the time an interruption happened and how long was left. That note, not the software, is what makes the re-sit decision fair.
The five lines to write down before the next exam
None of this needs a meeting. It needs one paragraph in the exam instructions that the invigilator has read.
- Who decides. One named person decides re-sits, in the room, during the exam. Not a committee afterwards.
- What the student does first. Reopen the same browser on the same machine. Not a different device, not a private window.
- What happens to the time. Decide now whether an interrupted student gets the remainder, a fixed extension, or a fresh sitting. Write the number down.
- The objective-paper exception. An MCQ paper restarts empty. That is the case most likely to need a fresh sitting rather than extra minutes.
- If submit fails. Do not close the tab. Retry. If it has retried and failed, photograph the screen and raise it the same day, while the attempt can still be reopened.
Every school running online tests will have this happen within the first term. The schools it goes badly for are not the ones with worse infrastructure — they are the ones where nobody had decided, so a teacher improvised in front of thirty students and then had to defend the improvisation to a parent.
What a half-finished paper does to the figures you report is worked through in what an absence does to a class average, and the wider set of operational problems is in the challenges schools face during assessments. The exam-day behaviour itself is part of the assessment software for schools.