DevicedialCan you show the fault was there before the cover ran out?
One bad reading is a story. A dated column of them is a record, and only one of the two survives a support desk.
One gear check a month
MonthlyOne thing a month worth measuring before it fails properly โ a mic that reset itself, a stick that drifts, a switch sending two clicks. Two sentences and the test.
Free to use โ Pro is for keeping it
This tool, like every other one here, is free and needs no account. A free account keeps three setups and three email alerts. Pro takes the ads off every site we run and lifts that to 200 setups and 50 alerts, adds a public page for any result and lets you embed the tool without our badge.
Try also
How do I prove a device is faulty for a warranty claim?
The Devicedial warranty claim log keeps one dated row per reading with the limit it should have stayed inside, and counts how many readings went past it. Each row holds the date, which test it came from, the number you measured and the number it was meant to beat. A switch tells the sheet which side is the fault, so a chatter gap under 50 ms and a noise floor above โ60 dBFS can sit in the same column without contradicting each other.
The count is the point. Support desks are used to descriptions โ it crackles, it drifts, it feels slow โ and those are indistinguishable from a bad day. Nine dated readings with three past the limit are not. It matters most for intermittent faults, the kind that behave perfectly in front of a technician, because a column with dates is the only form of evidence you can gather before the thing fails completely.
A limit for each test that a support desk cannot wave away
A limit is only worth logging if it came from somewhere other than your patience. These come from the specification, from the test's own scale, or from your first reading when the device was new.
| Test | What it returns | Where the limit comes from |
|---|---|---|
| Refresh rate test | The rate actually delivered, in Hz | The rate printed on the box |
| Polling rate test | Reports a second, in Hz | The rate printed on the box |
| Double click test | Presses that sent two edges under 50 ms apart | Zero events; the 50 ms threshold is the test's own |
| Stick drift test | A drift score from 0 to 100 | Above 20 a standard deadzone stops hiding it |
| Dead pixel test | A count of dead and stuck pixels | The panel's own fault class, from its warranty page |
| Mic test | Peak and background noise in dBFS | Your own reading from when the device was new |
| Camera test | Resolution and frame rate being sent | What the specification claims |
| Keyboard tester | Which keys register and how many at once | Every key, and the rollover the board was sold with |
Where a limit is your own baseline rather than a published figure, log the baseline reading too. A column that starts with the device working is far harder to dismiss than one that starts on the day it annoyed you.
Which tests produce a number worth logging
The ones with a scale rather than a verdict. The double click test counts presses that sent two edges less than 50 milliseconds apart, which is switch chatter and not something a hand can do. The stick drift test gives a score from 0 to 100, and the guide to how bad a drift score is explains where the thresholds come from. The mic test reports peak level and background noise in dBFS, the refresh rate test the rate actually delivered, and the dead pixel test a count you can photograph.
Before you open the claim
Read the reading back once. A monitor delivering 60 Hz is usually a cable or a setting rather than a panel, and the guide on a monitor stuck at 60 Hz rules those out in a few minutes; a dead pixel is worth separating from a stuck one with the guide to the difference, because the two are graded differently. A claim that survives is one where the obvious explanations were eliminated first, and the log is where you record that they were.
If the readings are still inside their limits, the gear test schedule is the better next step: keep measuring on a date, and the column will be ready if the day comes.
Frequently asked questions
The fault only shows up sometimes. Is a log still worth keeping?
That is exactly the case it exists for. An intermittent fault is the hardest kind to claim on, because the only demonstration anyone will accept is one that happens on demand and this one will not. What you can produce instead is frequency: twenty dated readings with six past the limit describes a device that fails roughly a third of the time, which is a fault. Log the good readings too โ a column of nothing but failures looks selected, and the share below the total is only meaningful if both are in there.
How long is a device covered after I buy it?
It depends where you bought it, and it is worth checking before you decide a fault is your problem. In the EU, goods come with a legal guarantee of conformity of at least two years from delivery under Directive 2019/771, which sits alongside any manufacturer warranty rather than replacing it. In the United States the Magnuson-Moss Warranty Act governs written warranties and state law adds implied ones. Either way the useful thing to hold is a reading with a date on it from inside the covered period.
What limit should I use when the specification does not give one?
Your own first reading, taken when the device was new and working. Most of what people claim on has no published threshold โ how quiet a headset’s noise floor should be, how much a stick may rest off centre โ but every one of them has a value it started at. That is why the test plan for a new machine is worth running on gear that seems fine: it produces the baseline this log compares against, and a baseline recorded before there was a dispute is worth more than one reconstructed after.
How the test works
Sources: