A test result matters only if it changes what you do next.

DeviceOK is built around fault isolation, not a list of generic fixes. It separates what the browser actually observed from what the operating system, application or manufacturer documents.

Diagnostic sequence

Five layers from symptom to decision

Reproduce the symptom

A useful diagnosis starts with a repeatable failure condition: which device, which app or browser, which connection, and what the user actually sees or hears.

Collect the strongest available evidence

DeviceOK prefers a direct browser-visible result—signal present, camera stream available, key event received, controller axis movement, network timing, permission state—over a guessed cause.

Separate layers

The same symptom can originate in hardware, cable/power, operating system, permission, browser, app selection or routing. A pass at one layer moves attention upward; a failure across independent contexts moves attention downward.

Change one variable

Troubleshooting becomes unreliable when drivers, cables, permissions and applications are changed together. DeviceOK favors reversible single-variable changes followed by the same retest.

Escalate at the boundary

When the browser cannot observe firmware, electrical state, SMART health, internal battery condition or protected OEM diagnostics, DeviceOK stops claiming certainty and points to the appropriate native/manufacturer path.

Interpretation

Confidence is not binary

A browser can prove some observations and only narrow others. The wording on a page should reflect that difference.

LevelWhat it meansHow to use it

ObservedDeviceOK directly received or measured the browser-visible event during this session. Example: live microphone samples arrived from the selected input.Use it as the next branch condition.

Strongly supportedTwo or more observations materially narrow the fault, but an inaccessible layer remains. Example: a camera works in DeviceOK and another browser app but fails only in one meeting app.Confirm with another observation before an invasive change.

PossibleThe cause fits the symptom, but the current evidence does not distinguish it from alternatives. It should stay behind higher-signal checks.Confirm with another observation before an invasive change.

UnknownThe browser or available source cannot establish the state. DeviceOK should say so rather than turn absence of evidence into a hardware diagnosis.Use native/OEM diagnostics or another independent test.

Cause ordering

Low-risk, high-information checks come first

Before drivers or replacement

Correct device/input/output selected
Permission and privacy access
Mute, disable, gain or obvious configuration
Direct cable, port, wireless and power path
App/browser routing and contention
Operating-system recognition and configuration
Official driver, firmware or native diagnostic
Physical damage or probable component failure

Why this order

Selection, permission and connection mistakes are reversible and often distinguishable with direct tests. Firmware changes, registry edits, disassembly and replacement are higher-risk actions and should come only after evidence has moved the fault below the software/configuration layers.

The order changes when safety is involved: swelling batteries, burning smells, exposed mains wiring, liquid damage or data-recovery risk should stop routine testing and move directly to a safe service path.

Browser boundary

What a web diagnostic cannot certify

Battery healthA web page generally cannot read protected cycle count, cell impedance or service-health data. Use OS/OEM battery diagnostics.

Drive healthBrowser storage quota is not SMART/NVMe health. Use the operating system or drive maker for physical-drive diagnostics.

USB-C capabilityConnector shape does not prove power, data generation or display mode. Model/port/cable documentation is required.

Firmware and electrical faultsA browser cannot safely measure internal voltages, board-level faults or every firmware state. Use documented native diagnostics and professional instruments where appropriate.

Every useful fix ends with a retest.Use the same device, connection and test condition where possible. If the symptom changes, start a new branch instead of forcing the old diagnosis to fit.

Start a diagnosis