How Earnify Handles Pool Failover and Connection Resilience

Explore how Earnify's browser-based mining platform maintains uptime through automatic pool failover, WebSocket reconnection, and zero-server architecture for publishers.

The Challenge of Browser-Based Mining Uptime

Every second of downtime in browser-based cryptocurrency mining translates directly to lost revenue. For a publisher with 50,000 monthly visitors averaging 3-minute sessions, a single 30-second connection drop across just 10% of active miners can mean thousands of missed hashes. Unlike server-side mining rigs that sit in climate-controlled data centers with redundant power supplies, browser miners operate in the wild—on laptops closing their lids, on spotty coffee shop Wi-Fi, on mobile hotspots that flicker between 4G and 5G.

Earnify's zero-server architecture adds another layer of complexity: there is no central server to buffer shares or queue work. Every millisecond of connectivity matters because the mining logic lives entirely in the visitor's browser, communicating directly with the pool via WebSocket. This design eliminates infrastructure costs and privacy concerns—zero data collection, no cookies, no tracking—but it demands a failover system that can react instantly when a pool endpoint becomes unreachable.

WebSocket Stratum: The Backbone of Earnify's Connection

Before diving into failover mechanics, it's worth understanding what's actually being protected. Earnify connects to mining pools using the WebSocket Stratum protocol—a lightweight, persistent connection that carries mining jobs, share submissions, and difficulty adjustments between the browser and the pool.

Unlike traditional HTTP-based polling (which would waste bandwidth and CPU cycles constantly asking "got any new work?"), WebSocket Stratum maintains a bidirectional pipe. The pool pushes new block templates immediately when they arrive, and the miner pushes valid shares back. This real-time communication is what makes browser mining viable at scale—latency between a new block and the miner starting work on it averages under 80ms on a healthy connection.

The connection isn't just fire-and-forget. Earnify's WebAssembly mining engine, running inside a dedicated Web Worker, continuously monitors three health signals:

• Heartbeat response time: If the pool doesn't acknowledge a ping within 5 seconds, the connection is marked as degraded.
• Job refresh interval: If no new mining job arrives for 60 seconds (when the network is actively finding blocks), something is wrong.
• TCP socket state: The browser's native WebSocket API exposes readyState; Earnify polls this every 500ms.

How Automatic Failover Works

Earnify's failover system operates on a priority-weighted pool list that publishers can configure directly in the script tag's data-pools attribute. When the primary pool fails any of the three health checks above, the system doesn't wait—it immediately begins the failover sequence.

Detection and Trigger Logic

The failover trigger isn't a simple binary. Earnify uses a weighted scoring model that prevents flapping (rapid switching between pools due to transient issues):

This scoring system means a single heartbeat miss won't trigger a disruptive failover—it takes sustained evidence of a failing connection. However, a hard WebSocket close (like a pool server crash) triggers instant failover with zero hesitation.

The Failover Handshake

When the score hits 70, Earnify executes the following sequence in under 1.2 seconds on average:

1. Graceful close: The failing WebSocket is closed with a 1000 status code, freeing the port immediately rather than waiting for a TCP timeout.
2. Pool selection: The next pool in the priority list is selected. If Pool B was recently marked as problematic (via a cooldown timer), it's skipped for Pool C.
3. Stratum subscribe: A new WebSocket opens to the backup pool. The mining.subscribe message includes the session ID from the previous pool where possible, allowing some pools to resume work without a full re-authorization.
4. Difficulty renegotiation: The backup pool may assign a different difficulty. Earnify's engine adapts instantly—there's no "ramp-up" period for the WASM miner.
5. Share buffer flush: Any shares that were queued but unsubmitted on the failed connection are discarded (to prevent double-submission issues), and mining resumes fresh on the new pool.

Connection Resilience Beyond Failover

Failover handles the "pool is dead" scenario, but what about the 95% of connection issues that are transient? Spotty Wi-Fi, browser tab throttling, and laptop sleep/wake cycles cause far more interruptions than pool outages. Earnify's resilience layer addresses these with a different toolkit.

Exponential Backoff Reconnection

When a WebSocket drops due to a client-side network issue (not a pool failure), Earnify doesn't immediately fail over to a backup pool—that would be wasteful. Instead, it attempts reconnection to the same pool using exponential backoff with jitter:

This approach prevents "thundering herd" problems where thousands of browser clients simultaneously hammer a recovering pool. The jitter (random 0–1000ms addition) ensures reconnection attempts are staggered across the visitor base.

Earnify will attempt reconnection up to 5 times with this backoff pattern. Only after all 5 attempts fail (roughly 90 seconds total) does it trigger a full failover to the next pool in the list. This patience pays off: in production data, 78% of transient disconnections recover within the first 3 reconnection attempts.

Tab Visibility and Throttling Awareness

Modern browsers aggressively throttle background tabs—Chrome limits timers to once per minute for tabs that have been backgrounded for 5+ minutes. This can make a perfectly healthy WebSocket appear dead because the JavaScript event loop is frozen.

Earnify's mining engine runs inside a Web Worker, which is less susceptible to throttling than the main thread, but it's not immune. The system uses the Page Visibility API to detect when a tab goes background and adjusts its health-check expectations accordingly:

• Foreground tab: Heartbeat every 30 seconds, failover score accrues normally.
• Background tab (0–5 min): Heartbeat relaxed to 60 seconds, failover threshold raised to 90 points.
• Background tab (5+ min): Mining may pause entirely depending on browser behavior; WebSocket is kept alive but no failover is triggered if the connection appears dead—it's likely just throttling.

This prevents unnecessary failover cascades when a visitor simply switches to another tab. When they return, mining resumes instantly on the same pool with no reconnection overhead.

Real-World Performance Data

We instrumented Earnify across 1,000 browser sessions over a 14-day period to measure how the failover and resilience systems perform under real conditions. Here's what we found:

The data confirms what the architecture was designed for: pool-level outages are rare but handled instantly, while client-side disruptions are frequent but mostly self-resolving. The combination of these two systems means publishers using Earnify experience mining that feels continuous even when the infrastructure underneath isn't.

What This Means for Publishers

For a publisher evaluating browser mining solutions, connection resilience isn't a "nice to have"—it's the difference between a revenue stream that compounds reliably and one that leaks earnings through invisible gaps. Here's the practical impact:

The gap between "no failover" and "Earnify" represents real money left on the table—about $3.60/month for a mid-traffic site, scaling linearly with traffic. For a publisher doing 500,000 monthly visitors, that's $60/month in recovered revenue from connection resilience alone.

Configuring Your Pool List for Maximum Uptime

Earnify's failover system is only as good as the pool list you provide. Here's a configuration that maximizes resilience:

Key principles for pool selection:

• Geographic diversity: Include pools in different regions. A European pool and an Asian pool won't fail simultaneously due to a regional network issue.
• Different operators: Don't list three endpoints from the same pool operator. Operator-level outages (DNS misconfiguration, payment system issues) affect all their endpoints.
• Test latency: Each pool in your list should have <200ms ping from your primary audience's geography. Earnify will use them in order, so the first pool should be the lowest-latency option.

If you're using Earnify's default configuration (which automatically selects geographically optimal pools), you're already covered—the platform maintains relationships with multiple pool operators and routes traffic intelligently. But for publishers who want explicit control, the data-pools attribute gives you full sovereignty over your failover chain.

Ready to start mining with enterprise-grade connection resilience? Create your Earnify account and deploy in under 60 seconds. For a deeper dive into optimizing your mining revenue, check out our guide on CPU thread management strategies and how Earnify's n-1 threading model maximizes both mining performance and user experience.