How Long Does One Mouse Movement Count? We Measured It

Here is a question nobody seems to have published an answer to: when a tracker marks a second as active, how many seconds does one mouse movement actually cover?

It matters because almost every explanation of activity percentage, including ours until we measured it, implicitly treats an input event as a point in time. Move the mouse once, mark one second. That model is wrong, and the error is large enough to change what you would predict by a factor of two.

This is our own calibration data, from building and tuning an activity simulator against observed Hubstaff output. We are publishing the numbers and the method because nobody else has, and because the result is useful whether or not you ever use our software.

The naive model, and why it fails

Hubstaff's rule is simple and well documented: a second counts as active if it contained at least one mouse or keyboard event, and your percentage is active seconds divided by 600. We cover that in how Hubstaff activity tracking works.

From that rule, the obvious prediction is that an action every N seconds marks one second in every N, giving an activity of 1/N. An action every 4 seconds should produce 25 percent.

When we ran configurations and compared them against what Hubstaff actually reported, this consistently under-predicted. Not by a rounding error. By roughly half.

What we measured

We ran the simulator with known, fixed intervals for each input type, tracked a session, and read the activity percentage Hubstaff reported for it. Then we solved for the one unknown: how many seconds of activity credit each action is worth.

Call that value d, the effective tracker-visible duration of one action. If an action is worth d seconds and you repeat it every i seconds, the fraction of seconds that action marks active is d divided by i.

The headline finding is the first row. **A smooth mouse movement is worth roughly two and a half times what a keystroke is worth**, because it is not an event, it is a path. A cursor sliding 50 pixels generates motion events continuously for most of a second, and any second those events touch is marked active.

A key press is the opposite. However hard you hit the key, it is one moment. This is the mechanical reason behind something we and others have said repeatedly without being able to quantify it: typing furiously does not help your score.

Combining several input types

If you have more than one kind of input running, you cannot add the fractions. Two inputs that each cover 50 percent of seconds do not cover 100 percent, because they overlap.

The correct combination is over inactivity. A second is inactive only if every input type missed it, so you multiply the per-type inactive probabilities and subtract from one.

Where dᵢ is the action's value from the table above and intervalᵢ is the average seconds between actions of that type. The product runs over every enabled input type.

Does it hold up?

Here is the validation case, with four input types running at different intervals.

**Hubstaff reported 47 percent for that session.** The model predicted 47.5. That is close enough that we stopped adjusting, and it is the model running in the app today.

The naive model, for the same configuration, predicts 1/2.5 + 1/3 + 1/15.5 + 1/8 which is well over 60 percent before you even deal with the overlap problem. It is not in the right neighbourhood.

Three things this tells you

1. Mouse movement is the most efficient input

Per action, a smooth movement buys about 2.5 times the activity credit of a keystroke. If you are reading on screen and want your work to register, scrolling and moving beat tapping a key.

2. Diminishing returns arrive fast

Because the combination multiplies inactivity, each additional input type adds less than the one before. Going from one input type to two is a large jump. Going from four to five barely moves the number.

3. Why 100 percent is practically unreachable, and that is fine

To approach 100 percent you need the product of inactivity terms to approach zero, which means at least one input firing at an interval close to its own d value. Mouse movement every second, continuously, for eight hours.

No human does that, which is exactly why a flat 100 percent reads as automation to anyone reviewing a chart. The arithmetic and the credibility problem point the same way, which is covered in what is a good Hubstaff activity level.

Limits of this data

We would rather state these than have someone else discover them.

• •This is calibration against observed output, not instrumentation of Hubstaff itself. We measured what the number does, not what the code does.
• •The d values are specific to our own generated actions. A 50-pixel smooth movement is worth 0.9 seconds; a 5-pixel twitch is worth far less. Hardware jigglers producing a tiny repetitive nudge will not match this table.
• •Intervals in the model are averages. Randomized timing around a mean behaves close to the model, but heavily skewed distributions will drift.
• •We validated against Hubstaff. Upwork counts keystrokes and clicks rather than active seconds, so this model does not transfer directly. See how the Upwork tracker works.
• •Tracker behaviour changes. These numbers reflect what we observe in 2026 and we will update this page if that shifts.

Reproduce it yourself

You do not need our software to check this. The method works with your own hands.

1. 1Start a tracked session and do nothing but move the mouse slowly and continuously for ten minutes. Note the activity percentage.
2. 2Start another and tap a single key once every two seconds, as close to metronomic as you can manage, with no mouse movement.
3. 3Compare. If events were points in time, the second session should score around 50 percent. It will come in lower, around 18 to 20.
4. 4The gap between those two sessions is the effect this article is about.

If you run this and get materially different numbers, we would genuinely like to know. The email is on the FAQ page.

Why we published this

Ghost Mode is an activity simulator, so we have an obvious interest in people understanding this correctly. We also think the alternative is worse: a market full of tools making vague claims about looking human, with no published basis for any of it.

The numbers above are the ones in our own estimator, which is why the app can show you a projected activity percentage before you start rather than asking you to guess. If you disagree with the model, you now have enough to argue with it specifically, which is the point.

What the tool does with this is covered in mouse jiggler vs activity simulator, and the honest limits of the whole category are in can mouse jigglers be detected.