Worker and Rig Naming Conventions That Save You Hours
A pool dashboard reports hashrate per worker, not per machine you remember buying, so the name you type into the miner firmware is the only key that links a payout line to a physical box. A 30-machine farm at 200 TH/s each produces about 6 PH/s, roughly 0.00269 BTC — $227.90 of gross output a day at a BTC price of $84,692 — so one machine quietly dropping out costs about $7.60 a day, and a bad naming scheme is what turns a ten-minute fix into a two-week blind spot.
Key takeaways
- Name workers by physical position first — site, row, rack, unit — because that is the order in which you walk to a fault.
- One machine in a 30-unit farm is about 3.3% of hashrate; at 6 PH/s that is roughly $7.60 per day that an unnamed worker can hide.
- Keep a suffix for the coin or algorithm port so merged-mining workers on the same machine do not overwrite each other in reports.
- Never reuse a retired worker name: a decommissioned unit's history will merge with the replacement and destroy your uptime baseline.
The short answer
Use a fixed, parseable pattern such as site-row-rack-unit, all lowercase, no spaces, and keep it identical in the miner firmware, the pool worker list and your invoice spreadsheet. Everything else — monitoring thresholds, RMA paperwork, cooling fixes — hangs off that one string.
The convention does not need to be clever. It needs to be consistent, short enough to type forty times, and ordered the way you physically move through the building. A technician standing in aisle C wants the dashboard sorted so the failures in aisle C appear together; a name that starts with the machine's purchase year instead of its location guarantees you will read the whole list to find it.
How the mechanism works
When a miner connects, it authenticates to a pool with a worker name appended to the account. The pool then aggregates accepted shares, reject rates and current hashrate under that string, and settles payouts against the account as a whole.[1] Because settlement is per account, the worker name is not a billing identity — it is a diagnostic identity. That distinction is why a farm can be paid correctly and still be unable to find a fault.
Under the default PPS+ method the block-reward component settles hourly at current difficulty, which means the dashboard has fresh data to compare against, hour by hour. A worker whose reported hashrate drifts 40% below its neighbours shows up in that comparison long before the monthly revenue total moves. Under PPLNS the same per-worker view matters more, because distributions arrive in lumps tied to blocks and a missing machine is easier to miss inside a variable payout.[2]
Where miners get it wrong
The most common failure is naming by hardware model. A farm that labels machines s19-01, s19-02 and so on ends up with a naming space that silently collides the moment a second batch arrives, because nobody remembers that s19-01 is third from the left in row B. Names derived from a serial number have the opposite problem: they are unique but useless, since no human can walk to a serial number.
The second failure is treating the worker name as decoration and reusing it. Retire a dead unit, hand the same name to its replacement, and the pool's history for that worker becomes a spliced record of two different machines — the uptime curve never recovers and any comparison against a baseline is worthless.
The third is forgetting that one machine can appear several times. A miner pointed at two algorithms, or hashing an auxiliary chain alongside a parent chain, produces more than one worker entry, and a scheme with no room for that suffix will quietly overwrite or split reports in ways nobody notices until reconciliation. Multi-coin pools support switching between chains without moving hardware, so the same rig legitimately shows up on more than one chain over its life.
| Field | Example | Question it answers | What breaks without it |
|---|---|---|---|
| Site | osl2 | Which invoice and which power meter does this belong to? | Electricity cost per site cannot be allocated to revenue |
| Row | r04 | Where do I walk to reach it? | Faults cluster invisibly, an air-flow problem looks like bad luck |
| Rack and unit | c2-u11 | Which physical box is this, precisely? | Technicians pull the wrong machine, downtime doubles |
| Chain or port suffix | -btc, -aux | Which algorithm is this worker submitting for? | Merged-mining output is split or double-counted in reports |
Worked example: a silent 3.3%
Take 30 machines rated 200 TH/s each, 6 PH/s in total. Against the current network hashrate of about 1,003 EH/s, the farm's share is 5.98 × 10-6, and with 450 BTC mined network-wide each day the gross take is roughly 0.00269163 BTC per day. At $84,692 per BTC that is $227.90 a day gross, or about $218.78 after the listed 4% fee on the block-reward component.
Now suppose one of those machines loses a PSU fan and throttles instead of failing. Its reported hashrate falls to 60 TH/s. The farm total drops from $227.90 to about $220.30 a day — a 3.3% dip that a monthly P&L statement will attribute to difficulty or price. With worker-level names and per-worker hashrate on the dashboard, the same event is a single line at 30% of its neighbours' value, visible within one settlement hour.
The same arithmetic justifies the annoying discipline of naming before racking. Repointing 30 workers takes an afternoon; finding one throttling machine across a farm whose worker list reads worker1 through worker30 costs weeks of lost output. If you want a reference point for what a given hashrate should earn, run the numbers through the income calculator before you start hunting for a fault, so you know whether you are chasing 3% or 30%.
A checklist you can run today
- Freeze one pattern and write it down. Site, row, rack, unit, suffix — in that order, lowercase, hyphen-separated.
- Export the current worker list and sort it. If two names differ only by a capital letter or a stray space, they are two workers to the pool, not one.
- Compare per-worker hashrate against the model's spec. Any worker below roughly 90% of its neighbours is a candidate for a fan, firmware or PSU check.
- Cross-check pool totals with network data. Your pool's published mining statistics let you see whether a dip is your farm or the whole pool losing share.
- Retire names, never recycle them. Append a batch letter to a replacement machine so its history starts clean.
- Keep the pool's own view honest. The public pool-state page reports ViaBTC Pool Hashrate next to network hashrate, which is the number your per-worker sums should reconcile against at the end of each month.
Two hours of naming work buys a permanent audit trail. It also makes handover possible: a new technician can be told "yours is rows three and four" and can act on the dashboard without a tour of the building.
Frequently asked questions
What happens if my miner goes offline?
Shares stop, so expected income stops with them. Alerts and a dashboard that shows per-worker hashrate shorten the gap between a failure and a fix. The size of that gap is directly proportional to your farm's hashrate, which is why naming discipline scales: a single machine is a rounding error, a dead rack is not.
Is a bigger pool always better?
Size reduces payout variance but also concentrates hashrate. What matters more is fee structure, uptime, latency and payout cadence. For naming purposes, what matters is whether the pool's worker reporting is granular enough that you can actually see one machine misbehaving.
How long should a worker name be?
Long enough to locate the machine, short enough to type without checking. Ten to sixteen characters covers site, row, rack, unit and a chain suffix in most farms. If a name needs a lookup table to decode, the fault-hunting speed advantage disappears.
Name once, reconcile monthly
Adopt a pattern, rename existing workers during the next maintenance window rather than all at once, and add one rule: no two machines ever share a name. Then spend ten minutes a month summing per-worker hashrate and comparing it with the pool's published total. If the two agree and no worker sits consistently below its neighbours, your naming scheme is doing its job.
Data and sources: ViaBTC payout methods and fee schedule[1][2], ViaBTC earnings calculator[3]. Network difficulty 132.76 T, network hashrate, the 3.125 BTC block subsidy and a BTC price of $84,692 were read from public chain data and market feeds on 21 September 2026. Earnings figures are illustrative own calculations and change with difficulty, uptime and price.