When something looks wrong

Start here: open the address with /api/health after it, for example 192.168.0.10/api/health. It answers in a few words whether the server can work, and it is the first thing your supplier will ask for.

{ "ok": true, "target": "onsite", "uptimeSeconds": 1360,
  "database": { "ok": true, "latencyMs": 41 },
  "data": { "ok": true, "freeMb": 9176 },
  "warnings": [] }

A hall machine cannot open the address at allCopy Anchor Link

In order:

1. Is the server switched on, and is its network cable in?

2. Has its address changed? On the server, run hostname -I. If the number differs from the one on your card, that is the problem — and worth fixing permanently by reserving the address for that machine.

3. Is another machine using that address? Two machines with one address is the classic cause of "it worked yesterday".

4. Can the server see itself? On the server:

   Copy Text

   curl -s localhost/api/health

   If that answers and a hall machine cannot, the problem is the network between them, not openCBT.

The page loads but says the server is unwellCopy Anchor Link

The health page names the part that is wrong.

• database not ok — the database did not answer. On the server:

  Copy Text

  cd ~/deploy
  docker compose -f compose.onsite.yml ps

  If db is not healthy, restart the stack:

  Copy Text

  docker compose -f compose.onsite.yml restart

  If it still will not start, call your supplier. Do not delete anything.

• data not ok — the disk where pictures and backups live is full or unwritable. Check freeMb on the same page. Downloading and then deleting old backups is the usual fix.

• A warning about free space — it still works, but it is telling you the disk is nearly full. Deal with it before the next exam, not during one.

Students cannot sign inCopy Anchor Link

• "Incorrect credentials" for everyone: they are probably typing the wrong registration number format. Check one student's number in People.
• "You are already signed in on another machine": the student started on a different machine. An invigilator releases them from the Hall page.
• "Too many attempts": the account locks briefly after repeated wrong passwords. It clears itself; an administrator can also reset the password.
• Students sign in but see no paper: the paper is not ONGOING yet, or they are not enrolled on that course. Both are visible on the paper's own page.

A paper will not startCopy Anchor Link

openCBT says why. Usually one of:

• the paper is still a draft, or has no questions;
• its session has been archived;
• somebody other than the author or the assigned invigilator is trying.

Something was deleted by mistakeCopy Anchor Link

Check the Audit page: it records who deleted what and when. Recovering it means restoring a backup taken before the deletion, which replaces everything else too — so weigh that against re-entering the lost work by hand.

An update went wrongCopy Anchor Link

Tell your supplier the version. It is on the health page as version, and in Settings. A server can be put back on the previous version quickly if they know which one it was.

What to send your supplierCopy Anchor Link

1. What you expected, and what happened instead.

2. The output of 192.168.0.10/api/health.

3. The last page of the log:

   Copy Text

   cd ~/deploy
   docker compose -f compose.onsite.yml logs --tail 50 app

That is nearly always enough to tell them where to look.