Where is my Train at Home queue position? Reading the T@H log

If you've been staring at Train at Home's window wondering whether it's actually doing anything, you're not imagining a bug. The information exists — it's just not where the official app shows it. This guide is the detailed version of what the optimal setup guide only touches on briefly.

Why the official app can't show this

The miner process itself calls an orchestrator endpoint, /register/queue_state, to report your position — but Macrocosmos's own backend has no handler for it:

register_set_queue_state exhausted retries (3): POST /register/queue_state failed 503:
{"detail":"unsupported: No handler for register.queue_state"}

That's a confirmed, reproducible dead endpoint, not a network problem on your end. The app's UI freezes on the last visible step (usually "Running speedtest...") while, underneath, the miner keeps advancing through the actual registration queue. The real state is written to the log the whole time — the UI just never learns to read it back.

Where to look

Every day, Train at Home writes a fresh log file:

~/Library/Logs/IOTA Train at Home/<YYYY-MM-DD>-cli.log

Everything below comes from grepping this file. You don't need to write to it, edit it, or do anything but read it.

The two fields that matter

Registration responses carry two fields worth tracking: 'position' and 'status'.

• 'position' is your numeric place in the admission queue. It's only present while you're still queued.
• 'status' is the current lifecycle word. Based on this app's own parser (which has watched this field across many real runs), the sequence is: queued → occasionally processing (an unconfirmed, transitional reading) → confirming (an attestation step) → confirmed (waiting for a layer slot to open up — this step alone can last hours) → succeeded (you've been assigned and are about to start training). A registration can also end in expired or failed instead of succeeded — seeing either of those means that particular attempt didn't go through, not that this guide or the app missed a state.

Once you're past the admission queue, the orchestrator stops sending a numeric position at all — later responses report 'status': 'confirming', 'confirmed' or 'succeeded' alongside 'position': None. Seeing None there isn't an error; it means you've already left the queue.

Reading it live

A simple way to watch this without any tooling:

tail -f ~/Library/Logs/IOTA\ Train\ at\ Home/*-cli.log | grep --line-buffered -E "'position'|'status'"

This streams every new line that mentions either field as it's written, so you can watch your position (or lifecycle status) change in near real time.

Trend arrows, rate and ETA

If you use subnera, the number in the menu bar is that same 'position' value, with a trend arrow next to it. The arrow is computed over the last 10 minutes of position changes, not the whole history, so it reacts to what is happening now:

Arrow	Meaning	What to do
▼	Moving toward the front	Nothing, it's working
=	Stable (under 0.15 places per minute either way)	Wait, queues pause sometimes
▲	Moving away from the front	Stop restarting the app

The open menu shows the exact rate, for example Queue: 1564 (-2.0/min): a negative rate means you are gaining places.

The ETA

The ETA divides your position by the current advance rate, so 1,564 places at 3 places per minute is about 8 h 40 min, shown with the clock time you should reach the front. It is a rough estimate, because queues do not move at a constant speed. If the queue advances by less than 0.1 places per minute, the menu says — (queue not advancing) instead of showing an absurd figure, and the ETA only appears while you are queued. Once registration starts it disappears.

The mistake that costs you the most

Don't restart the official app while you're queued. Doing so sends a fresh registration request, which the orchestrator answers with a new queue id — starting your position over from wherever the back of the queue currently is. If your position looks like it's climbing instead of falling, the most common cause on this Mac's own logs is exactly this: someone (often understandably) restarted the app hoping to "fix" a stuck-looking number, and re-queued themselves in the process.

If nothing else is obviously wrong, leaving it alone is usually the fastest way through.

When a restart is actually the right call

Only when the miner is really stuck, not when the screen is: the official app has crashed (the process is gone), or it is still running but its log has not been written to for several minutes. subnera shows off once the log has been silent for more than 2 minutes. Its opt-in Auto-restart on crash watchdog only acts after the log has been stale for more than 5 minutes, and it stays out of the way for 5 minutes after you stop or restart the app yourself, so it never undoes a deliberate action.

What's safe to ignore

Not every alarming-looking line means something is wrong. Notably:

Failed to run speedtest: Unable to connect to servers to test latency.

This is logged at debug level and is explicitly non-fatal — registration continues past it without issue. If your speed test itself looks unreasonably low rather than outright failing, that's a different (and more common) situation, covered in the speed test guide.

Phases at a glance

Beyond the admission queue itself, the log reflects a broader lifecycle. In rough order of what you'll typically see:

Phase	What's happening
starting	The app is launching the worker process.
queued	Waiting in the admission queue; 'position' is present and (hopefully) dropping.
registering	Past the queue; confirming/attesting/waiting for a layer slot ('position': None).
idle	Assigned a layer, but waiting on the orchestrator for actual work to arrive.
working	Actively training — you'll see lines like ✅ FORWARD complete, ✅ BACKWARD complete, and ✅ Optimization step #<n>.
resetting / off	The miner is restarting, or the app isn't running / the log has gone stale.

Once you see genuine training lines rather than queue or registration chatter, you're through — that's the payoff for having waited.

Let a tool do the reading for you

Everything above is a manual, terminal-based way to answer "where do I actually stand?" If you'd rather see it update automatically, subnera is a small, read-only menu bar app built specifically around this log: it shows your queue position, its trend, a rough ETA to the front, and your current phase without you touching a terminal. See how to install it. If you're running Train at Home on more than one Mac, subnera hub extends the same idea to a single dashboard for the whole fleet.

Checklist

1. Find today's log: ~/Library/Logs/IOTA Train at Home/<date>-cli.log.
2. Grep for 'position' and 'status' to see where you stand.
3. Remember: 'position': None after you've been queued means you've left the queue, not an error.
4. Don't restart the app while queued — it re-queues you at the back; the effect during the later registering phase is less certain, but still best avoided.
5. Ignore a debug-level "Failed to run speedtest" line; it's non-fatal.
6. Watch for real training lines (FORWARD complete, BACKWARD complete, Optimization step #) as the sign you've actually started.
7. Install subnera if you'd rather not grep manually every time (guide).

If you haven't installed Train at Home yet, start with the install guide. If something looks stuck well beyond what's described here, the troubleshooting guide covers the more persistent failure modes.