Reaction
Measurement
What a time tracker records, and what a browser tab never reaches
Two runs, one boundary. On a Windows machine nobody touched, we read live Hubstaff’s own client log second by second. On a Linux machine nobody touched, we ran six browser mouse jigglers at once against the system idle timer. Here are both sets of readings, the method, and the parts they do not prove.
Measured 11–13 August 2026. Last updated August 23, 2026.
40
minutes of an unattended desk with the engine verifiably running
76.8%
average activity the tracker recorded across those blocks
6
browser jigglers started at once on an untouched machine
0
idle-timer resets produced by any of them, in five minutes
The short version
A time tracker measures input that reaches the operating system. When it does, the tracker records it: 4 unattended ten-minute blocks, with our engine verifiably running for every minute of them, came out between 74% and 80%, averaging 76.8%. When it does not, no amount of animation on a web page changes the number: six browser jigglers running simultaneously let the system idle counter climb by 303.6 seconds across a five-minute run — the entire run — and reset it zero times.
Those two findings are the same line seen from both sides, and the second one applies to our own free browser tool exactly as much as to the others in the table. A browser tab can hold your screen awake. It cannot make a tracker think you are there.
Run one
What live Hubstaff recorded on a desk nobody was sitting at
Between 11 and 13 August 2026 we ran Reaction on a Windows machine under a live Hubstaff account and then read the tracker’s own client log, second by second, for the intervals when the machine was genuinely unattended. 4 ten-minute blocks met every criterion below, and they are the whole of what this run reports.
Method
The figures do not come from the web dashboard or from an exported report. They come from the Hubstaff client’s own log file, which writes per second and lets a ten-minute block be reconstructed more precisely than a rounded tile in a browser. One log line marks every second in which input arrived; a second line marks the seconds in which that input was exclusively injected. A second with the first line and without the second is a live human at the keyboard.
That distinction is what makes the selection criterion possible, and the criterion is the whole study:
- A block counts only if the tracker logged zero seconds of real human input in it — nobody touched the machine for the full ten minutes.
- A block counts only if it sits entirely inside one tracking session, so the denominator really is 600 seconds.
- A block counts only if Reaction’s own heartbeat log shows the engine running for every minute of it. This is the criterion the first version of this page did not have, and it is the only one that answers whether a reading is about this software at all.
- Activity for a block = seconds with input ÷ 600, rounded. The average is total seconds with input ÷ total seconds observed, so it can be checked by adding up the column. Nothing is smoothed, weighted or discarded for looking wrong.
Worth stating because most vendors are vague about it: the Hubstaff client on Windows does distinguish injected input from real input — it writes the distinction down. What these runs measure is that those seconds were still counted as input rather than dropped.
All 4 published blocks, in order
The 4 blocks that passed all three criteria, unsorted and unfiltered. The dashed line is the 76.8% average.
The blocks the figures are made of
| Date | Block | Seconds with input, of 600 | Activity |
|---|---|---|---|
| 2026-08-13 | 12:40 | 465 | 78% |
| 2026-08-13 | 15:20 | 458 | 76% |
| 2026-08-13 | 15:30 | 442 | 74% |
| 2026-08-13 | 15:40 | 478 | 80% |
Across the 4 published blocks: average 76.8%, range 74–80%, 40 minutes. 21 blocks passed the first two criteria over the three days; only these four passed the third, and the note beside this table says what became of the rest.
What the spread means
The range matters more than the average. A flat line parked on one number is exactly the shape pattern detection is built to notice; no human produces input in the same proportion of every ten-minute window of their day. A series that runs 74–80% without repeating is what a duty cycle with jitter produces rather than a constant — though on 4 blocks that is an observation about these readings, not a demonstration that the shape passes for a person.
This is also why we publish a range rather than a target. Anyone promising a fixed percentage is either not measuring, or producing the one pattern worth avoiding.
The correction this page carries
An earlier version of this page, published on 14 August 2026, put twenty-one blocks in the table above and quoted 52–85% with an average of 71.5%. That was wrong, and not by a rounding error. The selection criterion asked whether the machine had been touched and whether the block sat inside a tracking session. It never asked whether our own software had been running.
It had been, in four of them. In the rest the engine was paused, and the input the tracker recorded during those minutes came from something we have not identified. That makes them an open question about that machine and no evidence at all about this product, so they are not in the table — not because they were inconvenient, but because keeping an unexplained reading in would have inflated our own figures.
What survives is smaller and duller: 4 blocks, 40 minutes, 74–80%. This note stays here permanently instead of the numbers being quietly restated, because a study that hides its corrections is worth less than one with fewer numbers in it.
Run two
What six browser jigglers did to the system idle timer
The other half of the boundary, measured on 13 August 2026. Six browser-based mouse jigglers were opened at once — our own free browser tool among them — each started with its own button, after which the machine was left untouched for five minutes while the operating system’s idle counter was read every five seconds.
Why all six at once is a fair test
Because of the shape of the answer. If the idle counter rises monotonically for the whole run, then not one of the six produced any input the system counted — a single run settles all six simultaneously, and there is no ordering effect to argue about.
The counter itself is the one the desktop uses to decide you are away, read straight from GNOME’s idle monitor over D-Bus. It is the same reading Teams, Slack and time trackers act on when they move you to “Away”.
Three earlier runs were rejected by the bench itself and are not on this page: one where the control page never executed its script, and two where the idle counter dropped — someone had touched the machine. A drop looks exactly like a finding (“the tool created input!”) which is precisely why it has to invalidate the run automatically.
The readings
| What was measured | Value |
|---|---|
| Baseline idle before the tabs were opened, ms | 2 521 |
| Idle at the start of the run, ms | 71 628 |
| Idle at the end of the run, ms | 375 277 |
| Idle gained over 61 samples, ms | 303 649 |
| Screen-idle inhibitors held, min–max | 2–2 |
| Resets of the system idle timer | 0 |
The gain matches the wall clock to the second: 303.6 seconds of counted idle across a run of about 303.6 seconds. Not one millisecond of idle was given back by any of the six.
All six, and what each one actually did
| Tool | Kept the screen lit | Reset the idle timer |
|---|---|---|
| Reaction (control) | Yes | No |
| movemycursor.com | Not re-testable | No |
| keepawake.app | Yes | No |
| mousemover.me | Yes | No |
| mousejiggler.live | Yes | No |
| mouse-jiggler.com | No | No |
Both halves came out of the same run: the screen stayed lit throughout — two idle inhibitors held from the first sample to the last — while the idle timer ran as if nobody were at the computer. Holding a display awake and looking present to a tracker are separate things, and only the first is something a web page can do.
- 1. movemycursor.com held the screen when we measured it on 30 July 2026 and cannot be re-tested the same way now: its start button sells the first click to an ad network. Three consecutive clean loads sent the tab to an affiliate-tagged game promo, a trading site and a shopping page respectively, so a visitor who came to start a jiggler gets someone else’s advertising instead, and the tool starts on the second attempt at best.
- 2. mouse-jiggler.com is the honest one: it does not claim to be software. It draws a moving pattern on your phone’s screen, you rest a physical mouse on the glass, and the sensor sees motion. That genuinely works — because a real mouse is moving — and it needs a second device.
The finding that outlived the measurement
A browser wake lock is released the moment its tab stops being visible, and taken again when you come back. We watched it happen on our own page: two inhibitors with the tab on screen, one after switching to another tab, two again on return.
That is the specification behaving correctly, and the consequence for anyone relying on a browser tab is blunt: a jiggler left open in a background tab holds nothing at all. It works only while you are looking at it — which is exactly the time you do not need it.
What these runs do not prove
- They show what the tracker’s client recorded on that machine. A dashboard check matched on 30 and 31 July 2026, but it was not repeated on 13 August, so the wording throughout is “the tracker recorded”, never “the dashboard showed”.
- One machine per run, one operating system per run: the tracker figures are Windows, the idle-timer figures are Ubuntu 24.04 with GNOME on Wayland and Chrome 150. Idle accounting differs between desktops, and we have not measured macOS at all.
- The tracker run measured Reaction, not mouse jigglers in general. It says nothing about hardware dongles or other apps, and it is not a claim that any percentage is guaranteed on your machine or your account.
- 4 blocks and 40 minutes is a small sample. The range is what we stand behind; the average summarises four readings and is not a figure anyone should expect to reproduce on their own machine or account.
Repeat it yourself
Both instruments are ordinary and free. Nothing here needs our software to check.
The system idle timer (GNOME)
busctl --user call org.gnome.Mutter.IdleMonitor /org/gnome/Mutter/IdleMonitor/Core org.gnome.Mutter.IdleMonitor GetIdletimeReturns the milliseconds since the last input the system counted. Read it, wait, read it again: if a tool creates input the OS sees, the second number is smaller. Watch the browser tab stay visible while you do it — a hidden tab is refused a wake lock and the whole test collapses.
The screen-idle inhibitors
busctl --user call org.gnome.SessionManager /org/gnome/SessionManager org.gnome.SessionManager GetInhibitorsLists what is currently holding the screen awake, which is how a wake lock is told apart from actual input. A browser jiggler adds an entry here and changes nothing above.
The tracker’s own log
%APPDATA%\Hubstaff\logs\hubstaff.log
WindowsInput.cpp:349 Mouse: …/R…/I…/LI…
WindowsInput.cpp:293 Only injected input. Mouse: 0/R0/I17/LI0
On Windows the Hubstaff client writes per-second lines to its log directory. The first line below appears for every second with input; the second marks the seconds where all of it was injected. A second with the first and without the second is a human.
Citing this
The figures are free to quote with a link to this page. Journalists and researchers can request the raw run data — the per-second block extraction, the bench output with every sample, and the rejected runs — by writing to support@getreaction.app. We will also say plainly what we did not measure, which is usually the more useful half of an answer.
The app the tracker run measured
Reaction produces ordinary operating-system input while your machine is idle, with varied movement and timing instead of a fixed interval, and steps aside the moment you touch the mouse. The numbers above are what that looked like from the tracker’s side.