Online exams that survive a power cut

An online exam system survives a power cut by treating the student's device as the first copy of the data. Answers are written to local storage or IndexedDB as they are typed, the paper keeps running offline, and a retry queue syncs to the server once power and connectivity return — with idempotency keys so nothing is submitted twice.

Key Takeaways

• Save the answer locally before you send it anywhere; a write that only exists in memory is a write you have already lost.
• Give every answer a client-generated identity so the server can tell a retry from a genuine second submission.
• The submit endpoint must be idempotent — same key in, same stored result out, no duplicate paper.
• A "saved" indicator backed by real queue state stops candidates refreshing mid-paper, which causes its own outages.
• Test with a physical power cut, not a mocked network failure; the failure modes are different.
• Cap how late an offline submission may arrive, and flag anything past that window instead of accepting it silently.

What does online exam system reliability actually mean?

Reliability means the paper completes exactly once, no matter what the network, the mains supply or the device does mid-session. The measurable outcomes are narrow: no lost answers, no duplicate submissions, and a resume that returns the candidate to the same question seconds after the power comes back.

Why does a power cut break an exam that passes testing?

Most exam clients hold the answer in memory and POST it when the candidate clicks Next. Pull the plug at minute 40 of a 60-minute paper and everything typed since the last successful request disappears. The server has no session to restore, because the write never arrived.

When do you actually need offline-tolerant exam delivery?

You need it when candidates sit in school labs or rented halls with unreliable mains and shared Wi-Fi, and when a lost paper means a re-sit, a refund or a dispute. You do not need it for a proctored exam on locked-down campus machines behind a UPS and wired links — spend there on invigilation and network redundancy instead. If your wider continuity planning is thin, the same reasoning applies as in business continuity planning for web systems.

How does offline-first exam delivery work?

The client treats the device as the first copy of the record. Every answer change writes to IndexedDB or local storage and appends a job to an outbox queue; a background sync worker drains that queue when the link returns. Each queued item carries a stable idempotency key, so the server can reject a replay instead of storing a second submission.

The server stays the authority for deadlines and marking, but it is the second copy during the exam. That ordering is the whole design:

// Write locally first, then queue the sync job.
const attempt = { examId, questionId, answer, clientId };
await localDb.put('answers', attempt);        // durable on the device
await localDb.put('outbox', {
  ...attempt,
  key: examId + ':' + questionId + ':' + clientId
});

Our team can help you build that client and the sync endpoint behind it as part of custom software development, in your own repositories and cloud accounts.

Step-by-step: building an exam client that survives the cut

Build in this order, because the sync layer is worthless if the local write is not durable. Each step ends with something you can test on a single laptop before it reaches a lab or a paying candidate.

1. Freeze the paper locally. Cache questions, images and the paper structure in a service worker or a bundled manifest, so a dropped link does not blank the screen mid-question.
2. Write every answer twice. Persist to IndexedDB first, then enqueue the sync job. If the local write fails, the candidate should see that immediately rather than at submission.
3. Give every answer a client-generated identity. A per-attempt UUID plus the question id makes replays detectable. Never depend on a server auto-increment id you have not received yet.
4. Make the outbox an ordered queue with backoff. Retry on a timer with exponential backoff and jitter, and persist the queue across reloads. A short interval with jitter beats a tight fixed loop that hammers a recovering network.
5. Make the submit endpoint idempotent. Store the idempotency key under a unique index and return the original result on replay instead of inserting again. Test it by sending the identical payload twice on purpose.
6. Show real sync state. A small saved indicator wired to the queue, not to a timer, prevents panic refreshes — which cause more lost papers than power cuts do.
7. Cap the offline window. Decide how late a submission may arrive and flag anything past it for human review. Silently accepting a four-hour-late paper is worse than a flagged one.

Which configuration actually matters on exam day?

Three settings decide most outcomes: the retry interval, the idempotency window, and how long the server keeps an unsubmitted attempt alive. Get them wrong and you either duplicate papers or lose the tail of a session that reconnects after the invigilator has already collected the devices.

Setting	What it controls	Sensible starting point
Retry interval	How fast the outbox drains after reconnection	A few seconds with exponential backoff and jitter
Idempotency window	How long a replayed key is still recognised	Longer than the exam plus the travel time home
Attempt TTL	When an unfinished session is abandoned server-side	Well past the exam end, with an alert before it expires
Local storage quota	Whether a large paper can be cached offline	Check the quota and fail loudly, never silently
Deadline clock	Whether a late sync is accepted	Server time, never the device clock

How do you verify it before exam day?

Run a power-cut drill on real hardware, not only a unit test. Unplug the machine mid-answer, leave the client offline for a couple of minutes, reconnect, and confirm the answer lands exactly once. Repeat with a browser refresh, a device reboot and an abrupt network kill, and log what each drill produced.

Drills like this belong in the same runbook as your wider release checks, in the spirit of running a new system in parallel with the old one until you trust it.

What breaks first when the power goes?

The client's local write is the first thing to check, because everything else is downstream of it. If the answer never reached IndexedDB, no retry logic will recover it — and the server logs will look perfectly healthy, because nothing was ever sent.

Failure modes and how to debug them

Start at the client, then move outward. Open the browser's application storage and confirm the answer and the outbox entry exist. Next, watch the network panel for the retry request and check its status. Finally, query the server for the idempotency key.

• Answer present locally, no request ever sent: the sync worker is not running. Check that it is registered and that nothing cancelled it on page hide.
• Request sent, 4xx response: usually an expired token. The client should refresh credentials on reconnect, then replay the queue, not drop it.
• Two submissions in the database: the idempotency key is missing, or the unique index was never created. Fix the index before the next exam, not during it.
• Queue drains but the paper looks empty on resume: the local read path reads a different store than the write path. One schema, two accessors, tested together.
• Everything works, but the candidate refreshed: the saved indicator was lying. Wire it to queue state so people trust it enough not to reload.

For server-side visibility, expose queue depth and sync failures as metrics and alert on them; the Prometheus documentation covers the exposition format these clients and APIs usually emit.

What does this cost to run?

Cost is dominated by engineer time, not hosting. You are building a second persistence path, an idempotent endpoint and a reconciliation job, then testing all three under failure. The infrastructure itself is modest: a small API tier, a database, and storage for cached papers. Egress and storage class matter if you serve large media-heavy papers to many candidates at once. Confirm current figures with your cloud vendor's own calculator before committing, and treat UPS or generator coverage at the venue as part of the same budget conversation.

Security considerations

Offline mode means exam content sits on a device you do not control. Cache question text, not answer keys. Bind the local record to the candidate's session and re-authenticate on reconnect before the queue drains, so a shared lab machine cannot be used to submit someone else's paper. Set short-lived tokens with a refresh path that works offline, and clear local storage on logout. On the server side, treat every replayed payload as untrusted input, even when the key matches.

Common mistakes

• Treating "offline support" as a retry wrapper around the same in-memory state.
• Generating the idempotency key on the server, which defeats the purpose.
• Using the device clock for deadlines; candidates can change it, and so can a flat battery.
• Never rehearsing the human side — invigilators need a script for what to do when the lights go out, which is the same training problem as getting staff confident on a new system.
• Testing only on fast office Wi-Fi with a laptop that has never run a three-hour paper.

A realistic scenario: 240 candidates, one substation

A college in the Kathmandu Valley runs an entrance exam for 240 candidates across four labs. At 11:42 the substation trips. Mains is out for six minutes, the labs' UPS units cover the switches but not the desktops, and two machines reboot outright. Because the client wrote each answer to local storage on every change, the only real loss is the candidates' composure. When power returns, the outbox drains, the server sees one submission per candidate, and the invigilators extend the paper by the lost time. The recovery is boring, which is the point. That kind of assessment build is close to the work we did for an assessment and analytics institute.

Alternatives compared

Offline-first is not the only option. A thin web client with server-only state is far cheaper to build and perfectly adequate behind reliable power; a desktop exam app with a local database buys durability at the cost of distribution and updates; paper remains the fallback that never needs a retry queue.

Approach	Survives a power cut	Operational overhead	Best fit
Offline-first web client	Yes, if local writes and idempotency are done properly	Medium — sync layer, reconciliation, drills	Unreliable mains or shared connectivity
Thin web client, server-only state	No	Low	Proctored labs with UPS and wired links
Desktop exam application	Yes, strong local durability	High — installs, updates, device control	Fixed centres running the same hardware
Paper fallback alongside digital	Always	Medium — printing, collection, manual marking	Any exam where a re-sit is not acceptable

In short: save locally, sync later, submit once. Those three habits cover almost every power-cut scenario, and the rest is drilling them on real hardware before exam day.

People also search for

• Business continuity for a web system that must not go down
• Running a new system in parallel before you switch over
• Shared hosting, VPS or cloud for a high-traffic portal
• Training staff on new exam software
• When to replace a legacy exam system
• Why people quietly avoid the new system

If you would rather not carry this yourself, our team can help you design the offline-first client, the idempotent sync endpoint and the hosting behind it, then run the drills with your invigilators before the first real paper. Get in touch and we will tell you plainly what your current setup would survive.