Bitaxe “Flatline of Death”: Frozen Hashrate, Pool Alive, No New Shares

The “Flatline of Death” is the Bitaxe community’s own name for a specific failure: the AxeOS dashboard keeps showing a hashrate, the pool connection stays alive, but the hashrate graph goes flat and no new shares are ever found until you restart. The name was coined by owners in ESP-Miner issue #1053, opened 2025-06-20 and still open at last verification (see the record note at the end of this page), labeled bug, critical, hashing, accepted, with maintainers skot and WantClue assigned.

Here is the honest state of it in one paragraph: after more than a year and 110+ comments, there is no confirmed root cause and no confirmed firmware fix. A hardening PR (#1422) was merged in February 2026 and shipped in v2.13.0; some owners have been clean since, others still flatline — including a well-instrumented report on v2.14.2 from August 2026. The one mitigation owners have actually confirmed working is a share-threshold auto-restart watchdog, which we document step-by-step in the companion guide: Bitaxe auto-restart watchdog (AxeOS API). This page is the full evidence record — what the maintainers have said, what owners have measured, and what actually changed in the code.

In a hurry? Update to v2.13.0 or later, then run the share-threshold auto-restart watchdog. Everything below is the evidence for why those are the two moves.

The symptom signature — and how to confirm it is really this bug

All four signals together define the Flatline of Death:

From the original report by homecryptominer (issue body): “The hashrate still shows it’s hashing, but does not change and no new shares are found. On the AxeOS graph, this shows as a flatline (hence people calling it the Flatline of Death). … Sometimes it can crash in minutes, sometimes hours and occasionally days for this to occur. A restart will typically fix it.”

What the Flatline of Death is not

Route yourself to the right page before spending time here — several look-alike failures have their own fixes:

• Zero or low GH/s from the moment it boots — that is a hardware or configuration problem, not this bug. Start at Bitaxe not hashing / 0 GH/s.
• Gamma stuck at zero hashrate drawing only ~5 W — a distinct power-path signature: Bitaxe Gamma zero hashrate, 5 W power draw.
• The AxeOS web UI itself freezes or becomes unreachable while mining continues: AxeOS web UI freezes mid-session.
• Hashing stops after a Wi-Fi drop and never recovers — the stratum-reconnect variant: Bitaxe stratum API stuck after Wi-Fi timeout.
• Quick triage card for this exact error (symptoms, fix ladder, repair cost): Bitaxe — Flatline of Death error reference.

Affected hardware and firmware versions

Firmware: reports span v2.6.x through v2.9.0 in the early thread, then v2.10.1, the v2.11.0b6 beta, v2.14.0b1, and — as of 2026-08-10 — v2.14.2, the stable release at last verification. This is not a single-version regression, and downgrading has not cured it for anyone in the thread. (Status: Supported — user reports across the issue; not bench-reproduced by us.)

Two details owners keep confirming: it strikes “absolutely randomly” — one owner (dsaukou) has two Gamma 601s from AliExpress, one flawless and one flatlining since day one — and swapping PSUs, heatsinks, and thermal paste has not fixed it for anyone who tried (homecryptominer, dsaukou both reported full re-fits with no change).

The record: what the maintainers have said

Everything in this section is quoted from ESP-Miner collaborators in #1053, with dates. These are the most authoritative statements that exist on this bug.

“From the logs posted above it seems like the ASIC has just stopped sending shares. Network is still good. Hard to know if this is an ASIC problem or a problem with the esp-miner task that handles responses. I really wish I could reproduce this!”

— skot (ESP-Miner maintainer), 2025-07-04

“I wasn’t able to reproduce the Flatline of Death over the last week on 5 bitaxeGamma 601.”

— skot, 2025-07-14 — in the same comment he offered a free replacement Gamma to any US owner willing to mail in a failing unit

“I think I have reproduced this issue! On a Bitaxe Ultra 204. We had a power outage (or maybe a brownout) at my office overnight. … most of them were back on and working fine, but 3-4 of them had a power fault warning in AxeOS, and this one 204 had a flatline of death!”

— skot, 2025-07-17

The same day, an early oscilloscope observation was checked and withdrawn — worth recording because it still circulates:

“Looks like this was a loose connection on the Logic Analyzer. Not seeing any noise on the RST pin on the scope.”

— skot, 2025-07-17 — the “RST-pin noise” theory was retracted within hours of being raised

“My guess is there was a power fault that is causing the ASIC to reset. So now the ASIC needs to be initialized, but esp-miner is just sending work like nothing happened. This points to the need for that status task to be a watchdog for ASIC shares. I’ll see if I can put that together for a future esp-miner release.”

— skot, 2025-07-20 — the leading maintainer hypothesis, and the origin of the watchdog idea this page’s companion guide implements today (the general status task is tracked in issue #272, also still open)

“I received a Bitaxe (and PSU) in the mail from a user that was reporting regular FoD. It has been running for almost 2 weeks straight in my office with no sign of the issue. I’m starting to wonder if this bug is because of an AC Power quality issue before the PSU.”

— skot, 2025-09-23

“The build quality on many of the AliExpress Bitaxe hardware is bad.”

— skot, 2025-07-10 — AliExpress-sourced units are over-represented in the thread; GekkoScience and verified-retailer units appear too, so provenance is a risk factor, not the whole story

“I suspect this problem happens more frequently because you’re overclocked. But we should be able to handle errors like this more gracefully than FoD”

— skot, 2025-11-04, responding to a log capture from an overclocked Gamma

“To all here: is this still an issue?”

— mutatrum (ESP-Miner collaborator, author of PR #1422), 2026-03-31. One owner replied fixed-somewhere-along-the-way; another reported flatlines within 15 minutes on v2.14.0b1 four weeks later.

The record: what owners have measured

User reports are lower-confidence than maintainer statements, but two log captures in the thread are genuinely diagnostic:

1. The absurd stratum response times. Two owners caught the same artifact immediately before or during a flatline — Proximity-BBQ logged Stratum response time: 3630705.67 ms (~1 hour) on 2025-07-05, and nymkappa logged Stratum response time: 13438924.67 ms (~3.7 hours) on 2025-07-12 — with a healthy stratum_api: rx: line arriving one millisecond later, proving the pool link was alive. PR #1422 later reworked exactly this measurement path (see below).

2. The v2.14.2 telemetry capture (2026-08-10). The most instructive data in the whole thread: owner kerenskybr ran 30-second telemetry polling across three flatline occurrences on v2.14.2 (comment). During an 11-sample stall: hashRate_1m frozen at exactly 1213.9 the entire time, sharesAccepted frozen, while temperature took five distinct values, fan RPM ranged 3193–3327, and power stayed pinned at 16.5 W — the ASIC was still drawing full load and generating full heat. Their reading: the ASIC keeps hashing and the system keeps running; only the result/accounting path stops. An API restart recovered it within one sample. (Status: Supported — single well-instrumented owner report; consistent with skot’s “esp-miner sending work like nothing happened” framing but pointing at the result path rather than an ASIC reset.)

3. The pool anecdotes, for completeness. Chuth-ul got 4 days of clean uptime after moving from a ~150 ms-ping pool to eusolo.ckpool.org (2025-07-13) — but dsaukou saw the flatline across Braiins, Unmineable, public-pool.io, and eusolo alike: “there’s no difference what was pool” (same day). Treat pool-switching as an experiment, not a fix.

4. A USB power observation. One owner (IdotMaster1, 2026-05-17) reports their unit never flatlines while the USB port is also connected to a power brick or computer, and flatlines without it — a single-owner data point that fits the power-delivery family of hypotheses.

Competing explanations, honestly labeled

Nobody — maintainers included — has established the root cause. Here is every live hypothesis and where it stands:

PR #1422 — what it actually changed

PR #1422, “Misc. set of improvements and error checking” by mutatrum (branch name: flatline-research) was merged 2026-02-05 and first shipped in stable release v2.13.0 (2026-02-20). The PR body opens with the author’s own framing — “Hopefully fixes #1053” — and closes with “Thanks to @Mecanix-live for pointing out several of these issues.” That word “hopefully” matters: this was hardening of every suspicious code path, not a confirmed root-cause fix. We fetched and read the full diff (8 files, +138/−151). It changes, concretely:

• Rewrites the stratum line-receive buffer handling (components/stratum/stratum_api.c, STRATUM_V1_receive_jsonrpc_line): the old code split incoming JSON lines with strtok and a fragile manual memmove; the new code extracts lines with strchr/strndup and correctly preserves any partial next message left in the buffer. Malformed or unluckily-fragmented pool traffic could previously corrupt the parse stream.
• Hardens mining.notify parsing: the old code dereferenced pool-supplied JSON fields without validation and called abort() — a full device crash-reboot — if a job carried too many merkle branches. The new code validates the params array, its length, and each field type, and on any malformed job logs an error, frees everything, and skips the job instead of crashing.
• Fixes the stratum response-time measurement: the old implementation stamped the transmit time from inside a debug-logging function using the last parsed request ID — a mispairing that plausibly produced the nonsense hour-scale “response times” owners logged. The new code stamps at share submit (keyed to the actual send ID) and measures at receive. (That the artifact readings were caused by the mispairing is our reading of the before/after code — Status: Inferred.)
• Fixes a memory leak (the stratum task never freed error_str on rejected messages) and replaces an unbounded sprintf into the Wi-Fi status buffer with bounds-checked snprintf.
• Minor: response-time float precision plumbing end-to-end and AxeOS dashboard number formatting; a previously-disabled subscribe-parsing unit test restored.

Did it work? Mixed, and the issue is still open. nymkappa (who had earlier written the community watchdog) reported “I did not get this issue for 3+ months now” on the then-latest release (2025-11-11, pre-merge betas of this work); dsaukou replied the same day that nothing had changed on any release. Post-v2.13.0: one owner reports the problem quietly disappeared; another flatlined within 15 minutes on v2.14.0b1; and the 2026-08-10 telemetry report above is on v2.14.2. Fair summary: PR #1422 is real hardening of the exact code paths under suspicion, it plausibly reduced the incidence, and it did not end the bug. (Status: Verified for what the diff changes; Supported for the mixed field outcomes.)

What to actually do about it — the workaround ladder

1. Update to v2.13.0 or later (v2.14.2 at last verification). You get the #1422 hardening for free, and some owners have been clean since. Update guide: Bitaxe troubleshooting guide. Do not bother downgrading — every downgrade attempt in the thread failed to help.
2. Run a share-threshold auto-restart watchdog. The only mitigation owners have confirmed working: poll the AxeOS API, and if sharesAccepted stops moving for ~5 minutes, POST a restart. Full step-by-step with verified endpoints, a ready Bash script, and credit to nymkappa’s original: Bitaxe auto-restart watchdog (AxeOS API).
3. Check your power path. Given the maintainer’s brownout reproduction and AC-quality suspicion: try a different outlet/circuit, a quality 5 V supply, or a small UPS in front of the PSU. (Status: Inferred — follows the leading hypothesis; no controlled evidence it prevents FoD.)
4. Smart-plug power cycle as the blunt fallback. If the ESP32 wedges so hard the API stops answering, no software watchdog can save you — a smart plug on a daily schedule, or triggered by your monitoring, is the last-resort recovery. Cruder than an API restart (it cuts power mid-write), so use it as backstop, not first line.
5. Pool switch, as an experiment. Worked for one owner, did nothing for another. Cheap to try, unproven.
6. If restarts stop fixing it — or the “flatline” is actually 0 GH/s from boot — you are in hardware territory: Bitaxe not hashing / 0 GH/s, then Bitaxe repair & diagnostics if you want our bench to look at it.

Where DCENT_axe stands on this failure class

Our own ESP firmware, DCENT_axe (GPL-3.0, an original Rust implementation informed by ESP-Miner — full credit to Skot and the Bitaxe community), ships defensive mechanisms aimed at exactly this class of silent stall: UART frame-recovery with a fallback slot scan, a heap watchdog, and an optional periodic restart. We are not claiming it is immune to #1053 — per-board live soak evidence is still pending, and until our soak data says otherwise, the honest status of those mechanisms against this specific bug is Experimental. If you run stock AxeOS, the watchdog guide above is the proven path today.

FAQ

Is the Bitaxe Flatline of Death fixed in the latest firmware?

No — not confirmed fixed. Hardening from PR #1422 shipped in v2.13.0 (February 2026) and some owners have been clean since, but the issue remains open and a detailed flatline report on v2.14.2 was posted in August 2026. Update anyway; then run a watchdog.

Which Bitaxe models get the Flatline of Death?

Reported in #1053 on Gamma 601 (BM1370, most common), Ultra 204 (BM1366), Supra 402 (BM1368), and Max 1397 (BM1397), across firmware v2.6.x through v2.14.2. It strikes randomly — identical units from the same vendor can differ.

Does the Flatline of Death damage the hardware?

Nothing in the #1053 record shows lasting damage — every reported occurrence recovered after a restart. The cost is lost hashing time, which is why an auto-restart watchdog is the practical answer while the root cause stays unsolved.

Does switching pools stop the Flatline of Death?

Contested. One owner got four clean days after moving to a lower-latency pool; another saw flatlines on every pool tried, including the same one. It is a cheap experiment, not a fix.

Credits and sources

This page exists because the ESP-Miner maintainers debug in public. Thanks to skot and WantClue (assignees on #1053), mutatrum (PR #1422), Mecanix-live (credited in the PR for diagnosis), nymkappa (the original watchdog script), and reporters homecryptominer, komeana, dsaukou, Chuth-ul, Proximity-BBQ, IdotMaster1, and kerenskybr, whose captures are the evidence base above. Primary sources: issue #1053, PR #1422, and the ESP-Miner repository.

Record last verified: 2026-08-13. Every quote, issue state, and code reading on this page was checked against the primary source on that date.