Watching a school computer from far away: what the logs taught us about small computers

The logs from a tester’s computer in a remote town showed us a machine much smaller than the one we build on: 4 GB of memory (RAM, the working space a computer uses while programs run), against 64 GB on our development computer. We first suspected the memory. Later we found that the processor was the limit. Either way, we had not taken the size of the computer into account, and it changed how we think.

We only saw it because the program can send its logs home. Tziyun B’Rega runs on computers we will never touch. They are in schools, often far from us, in communities where IT help is thin or does not exist. When something goes wrong, nobody files a neat bug report, and a teacher may not even notice a problem until exam day. So from early on we asked ourselves a plain question: how do we see what the program is doing out there, without asking anyone to do anything?

Key points

• Logs from a tester’s computer in a remote town showed a computer much smaller than ours: 4 GB of memory against 64 GB.
• The program writes a diary of events and uploads it about every half minute. With no internet, the queue simply waits.
• Logs are meant to carry events, not student names or exam content. Without the address of our upload service, the feature stays off.
• We first suspected memory and later found the processor was the limit. We cannot change a user’s hardware, so the code manages the load carefully: a check of free memory, a lighter preview, an estimate of how long grading will take based on the computer’s real pace, and a weak-computer test.

An old idea that survived the move to Go

The first version of this appears in the project history on 19 February 2026, when the program was still an Electron (opens in a new tab) app: a small queue that saves things to upload, and uploads them when it can. When we moved to Go (opens in a new tab), we ported it, and our decision record (a short note we wrote when we chose between options) of 15 May 2026 describes the design.

Here is the idea in plain words:

• The program writes a log as it works, a diary of what happened, line by line.
• A background helper uploads today’s log every half minute or so. It keeps a queue of anything not yet sent, saved on disk, so if the computer is closed in the middle, the queue survives and tries again later.
• If there is no internet, nothing breaks. The queue simply waits.
• The upload goes to cloud storage that we run on our own private cloud. The computer does not hold a password or a key to our storage. It holds a time-limited upload link that can only write one thing. If someone found that link, the worst they could do is put one file there.

The decision record lists why we chose this. A third-party service that collects logs would need a secret key inside every copy of the program. Connecting remotely to a school’s computer is impossible when schools have no fixed address or IT person. And asking a teacher to email a log file is not a support process.

What is sent, and what is not

The log is a record of operational events: the program started, a step finished, a step failed, and some facts about the computer it ran on. The rule we wrote down is that logs must not carry student names, exam content or other personal details, and we designed the logs around that rule.

Each installation has a random identity that the program creates for itself on first run. From it, the program derives a friendly code name made of two words and a number, so we can tell installations apart without asking which school is which. The name does not say who the school is.

The upload only happens when the program has been given the address of our upload service. Without that address, the whole feature stays off and the program runs fully offline with no logs leaving the machine. The decision record says that is the default for any installation where we have not deliberately switched it on.

The worry: would it even get through?

A tester tried the program in a remote town. In the community the program is meant for, many people use filtered internet services, a filter between the computer and the internet that decides which sites and services it may reach, and we had no idea whether a connection to our private cloud would be let through. A block would have meant we were blind.

It was not blocked. The logs arrived, and we could watch them nearly live as the tester worked.

The surprise: the computer was small

At first we blamed the memory. The logs had shown us the machine’s specifications: 4 GB of memory, against the 64 GB of our development computer. On a big computer, almost anything works. On a small one, a program that holds a lot in memory, or does many things at once, becomes slow or crashes. We had been building on a machine many times bigger than the one that mattered.

What came out of it:

• The part that creates exam PDFs now checks how much memory is free before starting each further copy, and holds back when the computer is busy.
• The preview of the exam page steps down to a lighter mode on a weak computer, decided while the program runs, so the same copy can move between a fast computer and a slow one.
• The scan screen estimates how long grading will take from the pace of that actual computer, so a slow machine does not look frozen.
• Our automated tests now include a “weak computer” scenario with two cores and 4 GB, under heavy load.

The lighter preview comes from a decision record dated 23 October 2026, and the grading estimate from one dated 25 October 2026.

What we cannot claim

We want to be careful, because this is about a school. The logs are meant to carry events, not content. We have not run an audit that proves a log can never hold something personal. In the code we read, we did not find a screen where a school is told that logs are sent. The decision record says the sending is meant to be invisible to the teacher. We think that deserves a plain explanation to schools. We would rather say what we know than write a sentence that sounds better than the facts.

What we learned

Seeing the machine mattered more than we expected. A small computer in a remote town taught us something that building on a big computer never did. If you ship software to places you cannot visit, make sure you can see it, and be honest with the people running it about what you can see.

P.S. We later found out that we had the wrong suspect. It was not the memory, it was the processor. The whole path, from the raw scan arriving to the teacher seeing the marks, is limited by the computer’s processor (CPU). We reached that conclusion with off-the-shelf Microsoft testing tools. There is not much we can do about it, because it is the hardware of the person using the program. What we can do is write the code to manage the load carefully, so that a modest computer does not crash because of us.