Device Health Check
Get one clear picture of your hardware instead of a dozen scattered reports. Device Health Check collects the results of every test you have already run on this site — keyboard, mouse, display, audio, camera and USB — and turns them into a single health score, a prioritised list of faults and a set of cross-device findings that single tests cannot see. Everything runs locally in your browser.
What Is a Device Health Check?
A device health check is a structured diagnostic pass over the hardware attached to your computer. Rather than testing one component in isolation, it collects the outcome of every individual test into a single report so you can judge the machine as a whole. That matters because most real-world failures are not dramatic. A keyboard does not usually stop working between one keystroke and the next; it starts dropping the occasional press, and only a comparison against its own earlier results makes the drift obvious.
This page is the aggregation layer for every test on USBRecognized. When you open a keyboard, mouse, display, audio, camera or USB tool and complete a test, the result is written to your browser local storage under a stable key. Device Health Check reads those keys, normalises the different scoring scales each tool uses, and produces one weighted score plus a fault list. Nothing is inferred from hardware identifiers and nothing is uploaded; the page is a reader over data that already exists on your own machine. That also means the dashboard is only as informative as the tests you have actually run: it never guesses at the condition of a component it has no result for, it simply lists that component as untested.
How the Aggregation Works
Each individual test writes a small structured record: which tool produced it, a score on that tool own scale, a pass, warning or fail verdict, and a timestamp. When you load this dashboard, every record found in local storage is read back and mapped onto a common 0-100 scale. Tools that report a simple pass or fail are mapped to the top and bottom of the range so they stay comparable with tools that report continuous measurements.
The overall score is a weighted average rather than a plain mean. Components that are used constantly and fail loudly carry more weight than components that are optional or only occasionally relevant. A failing keyboard or display therefore moves the score more than an unusual result in a camera test, which keeps the headline number aligned with the faults that actually affect daily use.
Finally the correlation stage compares results across tools. It works on the most recent stored report from each tool rather than on a single sitting, so two results that both report input drops are more likely to point at a driver or power problem than at two unrelated component failures, and the dashboard says so explicitly instead of leaving you to notice the pattern yourself. Every finding carries a confidence level and is phrased as a possible cause, never a certainty. Where the evidence is suggestive but not conclusive, the dashboard reports the individual results and leaves the interpretation to you rather than inventing a link that the data does not support.
How to Read Your Health Score
The score runs from 0 to 100 and is intended as a triage signal, not a specification. A high score means every component you have tested is behaving within the range that test considers normal. A low score means at least one component returned a result that the corresponding test treats as a failure. Because the score is a weighted average, a single severe fault can pull it down sharply, which is deliberate: one broken keyboard matters more than four clean audio results.
Treat the direction of travel as more informative than the absolute number. If a machine scored 92 last month and scores 78 today with the same hardware, something has changed and the fault list will name it. If it has always scored 78, the score is simply describing a machine with a known weak component. Running the same tests on the same hardware at intervals is what turns the number into a useful signal. Compare like with like where you can: a test run while the machine was busy with other work may score differently from one run on an idle system, and that difference is not a hardware change.
What the Dashboard Measures
Aggregated Health Score
A single 0-100 figure combining every tool score you have generated, weighted by how much each component contributes to day-to-day reliability.
Per-Tool Result Cards
Each tested component gets its own card showing pass, warning or fail, the raw score, and the exact time the test was last run.
Cross-Device Correlation
Patterns that only appear once the most recent stored result from each tool is compared against the others, such as a keyboard and mouse both reporting dropped input.
Untested Component Tracking
Components you have never checked are listed separately so you can see the gaps in your diagnostic coverage at a glance.
Fault Prioritisation
Failures are ranked above warnings, and warnings above informational notes, so the most damaging problem is always the first thing you see.
Local Result History
The most recent result for each tool is retained in your browser, letting you compare the current state of the machine against the last time you tested.
Score Trend Awareness
Because each tool keeps its last result, a re-run that scores lower is visible immediately rather than being averaged away.
USB Subsystem Coverage
Enumeration, descriptor, power delivery and bandwidth findings from the USB tools roll up into one subsystem summary.
Display Subsystem Coverage
Dead pixels, backlight uniformity, colour banding, greyscale accuracy and refresh behaviour are combined into a single display verdict.
Input Subsystem Coverage
Key rollover, ghosting, chatter, polling rate, double-click faults and pointer tracking are merged into one input summary.
Audio and Camera Coverage
Microphone capture, speaker output, stereo channel separation, loopback latency and webcam frame delivery feed the same overall score.
One-Click Reset
Clear every stored report from local storage when you want to start a fresh baseline, for example after replacing a component.
What Each Subsystem Contributes
USB findings cover how devices enumerate, whether descriptors are well formed, whether power delivery is negotiated as expected and whether bandwidth is shared sensibly between endpoints. These results tend to be binary — a device either enumerates cleanly or it does not — so they carry high weight when they fail.
Display findings are the most granular. Dead and stuck pixels, backlight uniformity, colour banding, greyscale tracking and observed refresh rate are all measured separately and then combined. Because the display is the component you look at constantly, its subsystem verdict has a large effect on the overall score. A single stuck subpixel is a minor deduction; a cluster of them, or a backlight that is visibly brighter in one corner, carries considerably more weight because it affects every task you perform on the machine.
Input, audio and camera findings fill in the rest. Input tests catch degraded switches and sensor problems that develop slowly; audio tests catch noise floors and channel imbalance; camera tests catch frame delivery problems that are invisible in a still preview but obvious on a call. Together they make the difference between a machine that technically works and one that is pleasant to use.
Problems the Health Check Helps You Find
Keyboard chatter and double strikes
A key that registers two characters from one press usually scores badly in the rollover test, and the health dashboard flags it as an input fault rather than a text-entry annoyance.
Key ghosting on cheap membranes
Certain key combinations that fail to register at all point to a matrix limitation. The dashboard separates genuine ghosting from a keyboard that is simply dirty.
Mouse sensor jitter and angle snapping
Tracking tests reveal pointer drift, acceleration that cannot be disabled, and sensors that interpolate movement instead of reporting it honestly.
Double-click failures
A switch that fires twice per click wears out gradually. The dashboard keeps the last click-test result so the degradation is visible over weeks.
Dead or stuck pixels
Single stuck subpixels are easy to miss in normal use but obvious on a full-screen colour sweep, and they feed straight into the display verdict.
Backlight bleed and IPS glow
Uneven illumination, clouding and corner glow are graded in the display summary so you can tell a manufacturing defect from a viewing-angle artefact.
Colour banding and gradient steps
A panel that cannot render smooth gradients is usually running at reduced colour depth, a fault that shows up in the display subsystem score.
Refresh rate not applied
A monitor advertising 144 Hz while Windows still drives 60 Hz is a configuration fault. The display tests report the rate the browser actually observed.
Microphone hiss and low gain
Capture tests measure the noise floor and peak level so a quiet headset microphone is distinguished from a broken one.
Speaker channel imbalance
Stereo tests expose a dead channel or a driver that is noticeably quieter than its partner, which is a common cause of one-sided audio.
Camera frame drops and exposure hunting
Webcam tests report delivered frame rate and auto-exposure stability, catching the flicker and stutter that ruin calls.
Why Cross-Device Findings Matter
Some faults cannot be seen from a single test. If a keyboard alone drops keys, the likely cause is the keyboard. If a keyboard and a mouse both drop input in the same session, the more likely causes are a shared USB controller, a hub that cannot supply enough current, a driver problem or aggressive power management switching the ports off.
The dashboard compares the most recent stored report from each tool. It does not check how far apart those runs were, so a mouse tested in January and a keyboard tested in June are still evaluated together — which is why every result card shows the time that run was recorded, and why clearing the results before you switch machines keeps the picture honest. When findings are reported, each one names the tools involved so you can go back and re-run those specific tests.
Turning Findings into Fixes
Start with failures, not warnings. Open the tool named against each failed result and repeat the test on a known-good configuration where possible. A keyboard that fails rollover on one computer and passes on another is a functioning keyboard with a host-side limitation, not a defective unit. Re-testing in isolation is what separates a component fault from an environment fault.
For input faults, check the cable and the port before the device itself. Move the device to a port on a different controller, remove any hub from the path, and disable USB selective suspend for that device. Many reported ghosting and dropped-input problems disappear at this step because the device was never at fault. If the fault persists on every port and every cable, then the device itself becomes the leading suspect and the next step is to repeat the test on a second computer to confirm it.
For display faults, confirm the fault survives a change of source, cable and refresh rate. Dead pixels that move when you change resolution are usually a rendering artefact rather than a panel defect. For audio and camera faults, close other applications that may hold the device exclusively before concluding that the hardware has failed, since exclusive capture is a frequent cause of apparently broken microphones. If a microphone works in one application but not another, the fault is almost always a permission or device-selection issue rather than the hardware itself.
Diagnostic Guides
Building a Baseline for a New Machine
Test every component in a single sitting while the machine is new and known-good. That gives you a complete set of reference scores recorded under the same conditions, which is far more useful than a partial set collected weeks apart.
Note the score for each component rather than only the overall figure. When something degrades later, the component-level comparison tells you exactly what changed, while the headline number only tells you that something did.
Re-run the full set after the first major driver update. Vendors sometimes regress performance or power behaviour, and a comparison against your baseline catches it while the change is still easy to attribute.
Diagnosing Intermittent Faults
Intermittent faults are the hardest class to diagnose because a single test often passes. Run the suspect test repeatedly in one session and watch whether the result varies; a component that alternates between pass and warning under identical conditions is genuinely marginal.
Change exactly one variable between runs. Swapping the cable, the port and the device at the same time may fix the problem but leaves you unable to say which change mattered, so you cannot prevent the fault from returning.
Record the time each test was run. Timestamps are what let the dashboard correlate two tools, and they also reveal faults that only appear under load, such as when a machine is hot or when several USB devices are active at once.
Deciding Between Repair and Replacement
A component that fails on two different computers is faulty. A component that only fails on one computer is either fine or limited by that host, so replacement is unlikely to help and the money is better spent elsewhere.
Weigh the failure against the cost of the fix. A keyboard with one chattering switch is often worth cleaning or repairing, while a panel with several bright dead pixels is rarely worth an out-of-warranty repair compared with replacement.
Re-check the fault after any repair. Repairs that fix the symptom without addressing the cause tend to reappear within a few weeks, and a documented before-and-after score makes that obvious.
Preparing Evidence for a Warranty Claim
Capture results before contacting support. A stuck pixel is far easier to argue about with a full-screen colour test result recorded on the date of the claim than with a verbal description.
Show that the fault follows the device. Recording the same failure on a second computer removes the most common counter-argument, that the problem lies with your host or its drivers.
Record the failure in more than one condition where relevant. A display fault visible at native resolution and at a reduced refresh rate is much harder to attribute to configuration, and the extra evidence usually shortens the claim.
Testing After a Repair or Upgrade
Re-run the full set immediately after a repair, while the work is still under any repair warranty. A fault that survives the repair is a repair problem, and proving that within the warranty window is far easier than arguing about it months later.
When you upgrade one component, re-test the components that interact with it rather than the whole machine. A new graphics card changes the display path, and a new power supply can change how USB devices behave under load, so those are the results worth refreshing.
Keep the old baseline results written down before you upgrade. Once a test is re-run its previous score is overwritten, so the only way to state that performance improved or regressed is to have recorded the numbers beforehand.
Reading Results on a Shared or Managed Computer
On a machine you do not administer, some observations reflect policy rather than hardware. A port that powers down after a few idle minutes is usually a power-management setting, and a device that enumerates but cannot be opened is frequently blocked by a security product rather than faulty.
Run the tests in a normal session rather than a locked-down one where you can. Restricted environments can hide device interfaces entirely, which produces failures that say more about permissions than about the component you are trying to evaluate.
Because results are stored per browser profile, a managed machine may discard them when the profile is reset. Note the scores somewhere durable if you need them to support a ticket or a hardware request.
When to Run a Fresh Check
Run the full set after any hardware change, after a major operating system or driver update, and whenever you notice a symptom but cannot reproduce it reliably. Because each tool stores only its latest result, re-running a test overwrites the previous value, so the dashboard always reflects the current state rather than a historical average. That design keeps the summary honest at the cost of history, which is why noting the score after each run is worthwhile if you intend to track a machine over a long period.
A practical cadence for a machine you depend on is once a month, plus an immediate re-run after any driver update. Before buying a replacement component, re-run the relevant test on a second computer if you can: a result that follows the device is a device fault, while a result that stays with the computer is a host problem and a new component will not fix it.
Privacy and Data Handling
Every result on this page was generated locally and stored in your own browser. The dashboard reads that local data and renders it; there is no account, no sync and no server-side storage of diagnostic results.
Clearing the stored results removes them from this browser permanently. If you have enabled browser sync for site data, the records may be present on other signed-in devices with the same browser profile, so clear them from each device if you want them gone everywhere. Disabling the tests entirely is also unnecessary: no test runs in the background, and results only ever appear after you deliberately start one.
Quick Summary
Device Health Check aggregates every hardware test on this site into one weighted score, a prioritised fault list, and cross-device findings that single tests cannot detect. It reads only data already stored in your browser and never uploads your results.
Use it to triage: fix failures first, then warnings, and re-run the named test after each change so the score reflects the machine as it is now rather than when you last looked.
Device Health Check FAQ
What is a device health check?
It is a single report that collects the results of every hardware test you have run on this site and combines them into one score plus a fault list. Instead of reading six separate tool pages, you see which components passed, which are degraded and which have never been tested, along with findings that only appear when results are compared. The fault list is ordered by severity, so a failure appears above a warning, and the report names the tools involved so you can re-run those tests. Nothing about a component you never tested is guessed: it is listed as not tested, which keeps the summary honest when only part of the machine has been checked.
How is the overall health score calculated?
Each tool writes a score on its own scale. The dashboard normalises every result onto a common 0-100 range and then takes a weighted average, giving more influence to components that are used constantly and fail loudly. A single severe failure therefore lowers the score more than several clean but minor results raise it. The weighting is deliberately not a plain mean: an optional, rarely used component cannot lift a headline number that a constantly used one has dragged down. That mapping step is where a pass-or-fail tool and a tool reporting a continuous measurement become comparable at all, so read the score alongside the fault list.
Do I need to run every test for the dashboard to work?
No. The dashboard renders whatever results exist and lists the rest as not yet tested, so it is useful after a single test. The score becomes more representative as you add components, because a weighted average over one result is only describing that one result. A single completed test already yields a usable summary, because the panel marks the remaining components as not tested instead of guessing at them. What one test cannot do is produce a correlation finding: the stage only runs once at least two tools have a stored report, so a single-tool summary stays complete but silent on shared-hub or shared-driver causes.
Is any of my data uploaded to a server?
No. Every result is produced and stored locally in your browser under a per-tool key. This page reads those keys and renders them, and there is no account, no sync service and no server-side copy of your diagnostic data. Nothing is transmitted: a test never posts its result anywhere. Storage is bounded as well as local, because each tool retains only its ten most recent reports in this browser, so the history rolls over instead of accumulating forever, and clearing site data ends it immediately.
Can I use the health check on a phone or tablet?
The dashboard itself works in any modern mobile browser, and results are stored per browser so nothing is lost. Some tests are desktop-only because they need a physical keyboard, a mouse or a display that can be driven at a specific refresh rate, so a phone will typically have fewer components covered. Some individual tests need hardware that a phone or tablet simply cannot provide, such as a physical keyboard to register key events or a display driven at a chosen refresh rate, so those rows stay empty rather than showing a fake pass. Where a test does run on a small screen, its measurements are still the same measurements, which makes stored history comparable between machines.
What happens when I click Clear All?
It deletes every stored diagnostic report from this browser local storage. The dashboard then returns to its empty state and shows all components as not yet tested. This cannot be undone, so export or note any result you want to keep before clearing. Device permissions are a separate store, so clearing does not revoke camera or microphone access and you will not be re-prompted until a test asks for that device again.
Why did my score drop even though I changed nothing?
A drop with unchanged hardware usually means one tool returned a worse result than its previous run, and the fault list will name it. Common causes are a failing switch that has become marginal, a driver update that changed power behaviour, or a test run under heavier load than the original. The dashboard compares each new result against the previous stored one for that tool, so the drop usually has a name attached rather than being an unexplained change in a number. Two conditions are worth ruling out before suspecting hardware: a heavier background load than the earlier run had, and a driver or system update that changed how ports are powered.
Does a warning mean my hardware is broken?
Not necessarily. A warning means a measurement fell outside the ideal range but outside the outright failure range as well. Warnings are worth watching over time; many resolve on a re-run, and only persistent warnings justify replacing anything. Most warnings are environmental rather than mechanical: a keyboard on a low battery, a hub crowded on one controller, room light washing out a black screen, or a browser profile loaded with extensions. Re-run the flagged test after changing one condition at a time and let the fault list show whether the warning moved before you suspect the hardware itself.
Why are some components listed as not tested?
Because that tool has never been run in this browser. The untested list is there to expose gaps in coverage, which matters when you are judging a whole machine: a high score over two components says much less than a high score over eight. An untested component is neither a pass nor a failure, it is unknown, and a dashboard that silently dropped it would overstate the result. The list doubles as a plan: if you are buying, selling or warranty-checking a machine, the empty rows show exactly which devices you still have not verified with your own eyes.
Does reinstalling my browser lose my results?
Yes. Results live in browser local storage, so clearing site data, using private browsing, or reinstalling the browser removes them. If you track a machine over months, consider noting the score after each run so the history survives a browser reset. Incognito or private windows are the other common loss path, because in most browsers storage written there is discarded once the last such window closes. The practical defence is the export control on a finished report: keep that file with your maintenance notes, because the value of a hardware diagnostic is the trend across runs rather than one isolated number.
Are the tests safe to run on a work computer?
The tests are read-only from the hardware point of view: they observe behaviour rather than writing firmware or changing device settings. Stored results are held locally in the browser, so nothing leaves the machine, which is usually acceptable under a standard corporate policy. Read-only is a design constraint: no firmware is written and no device setting is rewritten, so an aborted run cannot leave a managed machine in a changed state. On a managed workstation the usual symptom is a blocked permission rather than a failed test, so if a check cannot start at all, review your policy or ask the local administrator before concluding that the hardware is faulty.
What should I do if every component fails?
Widespread failures usually point at the host rather than the peripherals: a failing power supply, an overloaded USB controller, aggressive power management or a corrupted driver stack. Test one device on a different computer before assuming several components failed at once. Start with the cheapest variables: a different port, removing an unpowered hub from the chain, a fresh cable, and the power plan set to full performance. Then re-run a single test. If the failures vanish together the host was responsible; if they follow the device to another machine the peripheral is, and that separation is why the checks are run as a set.