Own the job from report to resolution

Diagnosis is the study of cause

A symptom is what you can see going wrong, such as low hashrate or a missing pool worker. A cause is the reason it happened. Different causes can produce the same symptom. So start by describing the symptom exactly. Then think about what the miner depends on, such as power, network, the pool and cooling.

A useful check tells possible causes apart. Repeating a familiar action, such as a restart, can change the machine. If you do not know what its result would mean, it may also teach you very little. Before you run a permitted check, decide which result would support your current best explanation and which result would weaken it.

Scope separates local and shared problems

Scope means how much of the system is affected: one chain, one miner, a group on one switch, a row or the whole site. When many units fail together, look at what they share, such as a switch or a power feed. When only one unit is affected, compare it with similar healthy neighbors.

Scope helps you organize the search. It does not prove a cause. Two separate faults can happen at the same time. A shared problem can also affect only the units that are more sensitive to it. Combine scope with timing, configuration and your observations before you decide.

Independent does not mean unsupported

Before you start the actual task, confirm three things. Are you authorized? What does the site procedure say? Does the task need supervision or a second person? Managing a job on your own does not mean every physical task is safe to do alone. Before investigating, agree when you must stop and who you will escalate to.

Build a short list of explanations

Save the relevant logs and configuration before any reset or change. For each likely explanation, write down what you would expect to see if it were true. If the worker name is wrong, the work may show up under a different worker name. If there is a communication problem, the work is interrupted somewhere between the miner and the pool. Looking at the missing worker again only confirms the complaint. It does not tell the two explanations apart.

One useful check: through authorized access, compare the approved worker name for this miner with the name in its current configuration. If they do not match, look next at where the work is being credited. If they match, the communication question is still open. Write down what each result would mean before you ask for the check. Then every result changes your next decision, instead of you working through a list of things to try.

Close the loop

Where the procedure allows a change, make one change at a time and record what you changed and why. Before you act, plan how to undo it (rollback) and what you will watch afterward. Then check performance, alarms and accepted work against the approved baseline, for the length of time your site sets. Escalating with strong evidence is also a valid way to finish your part of the job.

Worked example: decide before restarting

A worker disappears from the pool, but you can still open the local status page of the miner. Possible causes include a hardware failure, a configuration error or a network problem further along the path to the pool.

Restarting the whole fleet would erase useful timing evidence and interrupt healthy units. First check how many units are affected, and compare the approved configuration with any recent changes. Reaching the status page shows the local network path works. It does not prove the miner can reach the pool. Write down the question each check answers, and keep every explanation the evidence has not ruled out.