Capture before changing the machine
The most useful incident record starts with what the machine did, not what you think failed. Write the exact message, indicator, sound, or loss of function. Add the local date and time, workload, and what stayed operational. A monitor that displays No Signal, a screen that goes black and returns, and a PC that loses power are three different observations even when they happen during the same game.
Save volatile evidence before a restart when it is safe to do so. That can include an on-screen error, an event timestamp, a container state, a temperature with its unit, or the name and version of a driver. The workbench does not run commands, change settings, restart services, erase logs, or decide that a part is bad.
Map the full path
Record the path between the thing producing data and the place the symptom appears. For a display that might be GPU → GPU port → cable or adapter → monitor input → monitor. For a drive it can be SSD → M.2 slot or cable → controller → firmware → operating-system driver. For a container it includes the container limit, parent cgroup, host memory, and time window.
Exact hardware and software identity keeps later tests comparable. Include model numbers, firmware, operating system, driver, application, and workload when they matter. A linked product from Hardware Projects stays attached when you edit the diagnostic record here.
Change one variable per controlled test
For each test, write four things:
- The one variable changed.
- The conditions held constant.
- The duration or number of repetitions.
- The observed result, including a unit where one applies.
If you changed a cable, driver, power limit, and graphics setting together, record that as an uncontrolled test. It may restore service, but it cannot show which change mattered. Keep destructive actions, firmware changes, and storage writes outside an improvised experiment; use the exact device documentation and a current backup before a step can put data or recoverability at risk.
Blank worksheet for JavaScript-off use
Copy this block into a local text file when browser scripting is unavailable:
Hardware incident title:
Record created (local date and time):
Last updated (local date and time):
Exact symptom:
Hardware and software:
Display, signal, storage, network, or container path:
Trigger, timing, frequency, and workload:
Recent change before the first event:
Observations and evidence:
Tests already run:
- Variable changed:
- Conditions held constant:
- Duration or repetitions:
- Observed result:
Outcome or next evidence checkpoint:
Read each export as a different privacy boundary
Save on this device keeps the Hardware Project in the current browser profile. The project URL contains a local ID, not the notes themselves, and it works only where that local record exists.
Download full JSON creates a complete portable record. It includes the title, linked product references, tool state, every diagnostic field, evidence records, and project dates. Treat that file as private if your notes contain serial numbers, hostnames, addresses, account names, file paths, or log excerpts.
Copy private summary produces readable plain text from the full diagnostic record. Review it before pasting because it can carry the same private details as the form.
Copy share URL without notes creates the limited Hardware Projects snapshot. The shared snapshot omits diagnostic text, evidence, free-form constraints, and the private use-case field. It can retain non-sensitive project structure such as the project type, title, linked product references, and supported tool state.
No browser-local save is a backup. Export the JSON before clearing site data, moving browser profiles, reinstalling the browser, or doing repair work that may affect the operating-system drive.