Time tracking without surveillance: how TimerOS classifies activity on-device

Almost every “employee monitoring” tool works the same way: it photographs the screen every few minutes, counts keystrokes, and ships all of it to a server for a manager to scrub through later. TimerOS was built on the opposite premise. It reads three small signals on the device, scores them locally, and sends none of the raw data anywhere.

That decision shapes everything downstream — what a manager can see, how much storage a year of tracking costs, whether the tool clears GDPR’s data-minimisation bar, and, mostly, how it feels to have it running on your machine. This post walks through how the classifier actually works, and shows the charts behind a normal tracked day.

The work stays on the worker’s machine, where it belongs.

— It is the principle the whole product is built around.

Two ways to measure a working day

Surveillance-style tools assume the worker is the problem to be watched, so they capture as much as possible and sort it out on the server. On-device classification assumes the opposite: capture the least you can get away with, turn it into a label on the spot, and keep the evidence on the device. The difference is not cosmetic.

Figure 1 · Two approaches, side by side

	Screenshot monitoring	TimerOS · on-device
What's captured	Screen images, keystrokes, mouse heatmaps	Active window title, app name, idle time
What leaves the device	Raw screenshots, uploaded continuously	Nothing raw — only the final time totals
What a manager sees	Hours of footage nobody will watch	Time states and activity labels
Storage per user / year	Gigabytes of images and logs	Kilobytes of structured totals
GDPR data-minimisation	Hard to defend — collects far more than needed	Minimal by construction
How it feels	Like being filmed at your desk	Like a clock that fills itself in

The same goal — knowing where the day went — reached two very different ways. The right-hand column is how TimerOS works today.

The three signals we read

The TimerOS desktop app runs quietly in the background and looks at exactly three things — nothing else touches the classifier:

The active window title — e.g. “Invoice #1042 — Acme” or “Pull request #88”.
The running application name — the foreground program, like your editor, browser, or design tool.
Time since the last input — how long since the last keyboard or mouse event, used to separate active work from idle.

From those three signals it can tell focused work from a coffee break, and that is enough. Everything a surveillance tool reaches for — the actual pixels, the actual keys — is left untouched.

What TimerOS never collects

No screenshots. No keystroke logging. No clipboard contents. No camera. No microphone. No browsing history. None of it is read, and none of it is stored — the desktop app does not have the code paths to do so.

How the classifier decides

Classification is a two-stage engine, and both stages run on the employee’s own machine. A fast, transparent scoring step handles the clear cases using rules — an editor in the foreground with recent input scores as productive; a long idle stretch scores as idle. A small optional local model handles the genuinely ambiguous moments, without anything leaving the device.

Crucially, the rules are not a black box. Employers configure the Activity Classification overlay — which apps and titles count as productive for their team — and employees can open a panel to see exactly how their time is being scored. Every minute lands in one of six honest states:

Productive — focused work in a counted app.
Idle — the machine is on, but no input for a while.
Break — a deliberate pause, tracked separately.
Overtime — work beyond the scheduled shift.
Off-work — outside working hours.
Offline — the app or machine isn’t running.

What a tracked day actually looks like

Because the output is structured time states rather than raw footage, it charts cleanly. Here is an illustrative day from a sample workspace — not customer data, but representative of what the dashboard shows each person about their own time.

Figure 2 · One day, by time state

8.2htracked

Time states · today

Productive66%

Break14%

Overtime10%

Idle10%

A sample 8.2-hour day. Productive time dominates; breaks and idle are visible but never editorialised — they are just states, not accusations.

Zoom out to a week and the same data becomes a rhythm — heavier mid-week, lighter on the weekend — without a single screenshot ever being taken.

Figure 3 · Productive hours this week

This weekproductive hours

6.2

7.1

5.4

6.8

2.1

0.6

MonTueWedThuFriSatSun

Each bar is a day's productive time. Thursday is this person's peak; the weekend tapers off, as it should.

And the numbers that matter for trust are small and fixed:

signals the classifier reads

screenshots ever taken

time states it can assign

classification runs on-device

Privacy by design, not as a setting

Reading three signals and scoring them locally is not a privacy toggle you can flip — it is the architecture. There is no “collect screenshots” switch hidden in an admin panel, because the capability was never built. That is what lets TimerOS clear GDPR’s data-minimisation principle comfortably and stay on the right side of the EU AI Act’s transparency expectations: workers are told what is measured, and they can see the rules that measure them.

On-device by design

Classification happens on the worker’s machine and reads only the active window title, the running application name, and time since last input. Managers see labels and time states — never raw screen content. See the monitoring notice for the full, plain-language version employees receive.

Time tracking earns its place only if the people it tracks would still install it knowing exactly how it works. That is the bar we hold ourselves to — and you can read more about why on the features page or the story behind TimerOS.