How We Test Hardware — Methodology

The verdict model: idle, insufficient, ok, warn, bad

Every tool ends in one of five states. Idle means waiting for input — no conclusion has been drawn. Insufficient means samples are arriving but below the minimum. The tool refuses to say either healthy or faulty at that point: a handful of clean samples proves a healthy device no more than a handful of dirty ones proves a broken one. Ok means the sampled data stayed inside the healthy envelope for this device class. Warn means a flag appeared but did not repeat — the sensor may be fine, or the event was caused by a cable, interference, or a dusty contact. Bad means the fault pattern reproduced at the configured threshold. The difference between warn and bad is repetition, which is why every page asks for a minimum amount of data before you read the verdict.

Why thresholds are configurable

A "fault" is not absolute. A resting stick value of 0.07 sits inside many games' default deadzone yet outside a competitive shooter's — it is early wear in one context and invisible in another. The same is true of switch timing: an 80ms double-press is almost certainly contact bounce, while a 150ms gap on a wireless mouse is more ambiguous. That is why the tools expose thresholds and let you re-grade the same recorded data instead of hiding the decision behind a fixed rule. The defaults match common baselines: stick drift thresholds of 0.05 / 0.08 / 0.12, chatter windows of 30 / 50 / 80 ms, and double-click windows of 80 / 100 / 150 ms.

How much data a result needs

Stick drift: rest the pad on a desk. The verdict unlocks once both sticks have 60 frames — about one second — but for a warranty claim, sample for at least ten seconds, roughly 600 frames per stick. The peak value matters, but so does the ratio of drift frames: one spike out of 600 and a hundred out of 600 are different diagnoses. Keyboard chatter: tap each suspect key five to ten times, and only call a switch worn when the flag reproduces on two separate runs at the same threshold. The verdict needs 25 presses in total and at least one key pressed five times, and the fault line is a chatter rate above 2%. Mouse double-click: run twenty or more clicks per button; a consistent rate above 5% on one button is the fault signature, an occasional gap is not. Rollover: hold four to six keys at once and watch the max count. CPS: one sprint of your chosen duration, and only compare numbers measured with the same technique — finger taps and jitter clicks are different sports.

Where the numbers come from

None of these numbers came out of a measurement lab, and we are not going to imply they did. They fall into three buckets — industry convention, engineering judgement, and sample-size floors — and the table says which is which:

The keyboard and mouse lines differ on purpose. A repeat under 50 ms on one key is close to impossible to produce by hand, so each flag is strong evidence and the line can sit low at 2%. A gap under 150 ms between two mouse clicks is something a fast finger produces routinely, so a single flag is weaker evidence and the line has to sit higher at 5%. If you disagree with any of these, change the threshold: the recorded data is re-graded against the new value, so the samples you already collected are not thrown away.

About the rate shown on a result card: it is flagged events divided by all presses. The first press of a button has no previous press to compare against, so it can never be flagged — but it stays in the denominator. That makes the displayed rate slightly smaller than a strict flagged-over-comparable count, which errs toward not calling your hardware faulty. We kept it that way on purpose: telling you a device is broken when it is not costs you a warranty claim or a replacement, and that is a worse error than asking you to click a few more times.

What every test can and cannot see

These tests read browser events: gamepad axis snapshots, keydown timestamps, mousedown gaps, pointer movement, and scroll wheel deltas. Browsers never expose everything. Windows and macOS reserve certain shortcuts (Win key, Cmd combinations), Fn and media keys are handled at firmware level, and PrtSc rarely fires a keydown at all. Polling rate can only be estimated, because browsers sample on their own animation frame cadence rather than the mouse's true rate. When a page says a reading is unavailable, it means the operating system or firmware consumed the event first — a limit we state plainly rather than hide. The keyboard test page documents exactly which keys never reach the browser.

What never happens with your data

All detection runs locally in the browser tab. No server receives your gamepad axes, key timings, click gaps, or camera frames. The retest history on each tool page is stored in your own browser's localStorage and can be wiped with a single Clear button. Result images are drawn on a local canvas and downloaded as PNGs — they are never uploaded. The only network requests a page makes are the page itself and the ad placements on result sections, and neither receives test data. For the full details, read the privacy policy.

How to turn a result into evidence

For a warranty claim, a reproducible bad verdict with a saved image beats a written description. Reset the stats, run the test again the same way, and confirm the same verdict appears. Then use the Save image button on the result card — the PNG carries the date, the numbers, and the page URL. Support teams accept this kind of local screenshot, and it costs you nothing. The fix guides — stick drift, keyboard chatter, and mouse double-click — walk you through what to do after the verdict, including when to re-test after a repair.